Default state: Decoding requests

What’s with that request variable, how do we define that? The structure
is described in the USB 2.0 spec, Table 9-2. It’s quite simple.

We are assuming here that the compiler will treat this structure as
packed, and that the `enum`s will be byte-sized. But that’s a sensible
assumption for an 8-bit controller and enum values less than 256.

You could stop now and ask if we really had to type out that request
structure and the enums. Surely there are already several places where
USB requests are already implemented, could we just grab a header from
them?

* The Linux kernel has a `<linux/usb/ch9.h>` header, named after the USB
  specification chapter 9. It is licensed under GPLv2 only, and that
  would be an unfortunate limitation for us if we want GPLv3.
* The `libusb` library has `<libusb.h>`, and it is licensed under
  LGPLv2.1 or later. But that file includes several others and declares
  libusb’s functions as well. A bit too heavy for us.
* There is, theoretically, also the Windows DDK. I don’t even want to
  consider making it a compile dependency for the firmware.

So, let’s for now just define all we need ourselves.

And that `utohs` function? Well, the USB specification dictates that all
multibyte values are sent in little-endian order. Our compiler, SDCC,
happens to use little-endian order as well, but not all 8051 compilers
are like that. The one that compiled the original TECK firmware, for
example, was a big-endian one. Better be explicit and define a couple of
macros to convert USB to native order and vice-versa. (They are named
analogously to `htons` and `ntohs`, Host to Network / Network to Host,
but using `u` for USB in place of `n` for Network.)