Improve the precision of error handling internally

[raphaelcohn]

I was looking at the internals of Device.get_ports(), and it swallows all the error codes returned by libusb, and even those that can never be.

This means that an downstream user can enter a state of unknown validity or impossible validity after checking the Result<_, Error> returned; not doing so violates the fail fast maxim.

Instead, code calling a third party C library must explicitly check for the documented errors it can return. In this example, it should do something like:-

	let mut port_numbers  = ArrayVec::new_const();
	let result = unsafe { libusb_get_port_numbers(device.as_raw(), port_numbers.as_mut_ptr(), MaximumDevicePortNumbers as _) };
	if likely!(result >= 0)
	{
		let count = result as usize;
		unsafe { port_numbers.set_len(count) };
	}
	else if likely!(result == LIBUSB_ERROR_OVERFLOW)
	{
		panic!("USB violates specification with more than 7 ports")
	}
	else
	{
		unreachable!("Undocumented error code from libusb_get_port_numbers(), {}", result)
	}

(likely! is a macro I use). Obviously, coding this for every call is tedious and time-consuming, but that's the cost of wrapping third party C libraries with their naive error handling strategies and use of a shared pool of constants.

Likewise this implies that rusb should (indeed, must) have more than one kind of Error.

[mcuee]

Potential workaround is to use libusb debug info for troubleshooting purpose, by setting LIBUSB_DEBUG env variable to a suitable value (eg: LIBUSB_DEBUG = 4).