Address state: Introduction

In the Default state, there was not much we had to respond to: a reset,
a `GET_DESCRIPTOR` for the Device descriptor, and a `SET_ADDRESS`
request. (High-speed devices also have to support `SET_FEATURE` for
`TEST_MODE` but we are not striving for that. Why would we need high
speed, we’re just a keyboard!)

In the Address state, things get more interesting.

* We still can be reset, suspended and resumed. (BTW we don’t implement
  suspend or resume yet.)
* We can be moved back to Default state by means of a `SET_ADDRESS`
  request with new address 0.
* We need to support more descriptor types in `GET_DESCRIPTOR`. (We dealt
  with that in the last series.)
* `GET_STATUS`:
  * for Device: whether we are currently self-powered (we’re not, TECK
    does not have a separate power cord) and whether we are currently
    configured to wake up the host from suspend (Remote Wakeup);
  * for Interface: we should report a Request Error by raising the
    `RXSTL` and `TXSTL` bits;
  * for Endpoint 0: report if we are in an error state (Halt). The spec
    says for Endpoint 0 it’s better not to report a Halt;
  * for other endpoints: report a Request Error.
* `SET_FEATURE` and `CLEAR_FEATURE`:
  * for Device:
    * `DEVICE_REMOTE_WAKEUP`: enable or disable the Remote Wakeup
      feature.
    * `TEST_MODE`: this is only required for high speed devices.
  * for Endpoint:
    * `ENDPOINT_HALT`: Halt an endpoint. We are not required to support
      this for Endpoint 0, and other endpoints are not enabled in this
      state so we always return Request Error.
* `SET_ADDRESS` with a non-zero new address: change our USB address and
  stay in Address state.
* `SET_DESCRIPTOR`: Nobody talks much of this request. It’s optional and
  very few people know what it might be useful for. Neither do we.
* `GET_INTERFACE` and `SET_INTERFACE`: Since we don’t have any
  Interfaces configured yet, return a Request Error.
* `SYNCH_FRAME`: Return a Request Error.
* `GET_CONFIGURATION`: The Address state is considered Configuration 0.
* `SET_CONFIGURATION` 0: Remain in the Address state.
* `SET_CONFIGURATION` with a non-zero Configuration value: Activate that
  configuration, moving into the Configured state.

In the next few commits, we deal with these.
Address state: Return to Default state on `SET_ADDRESS(0)`

Last time we used 0 as the sentinel value meaning “there is no
outstanding `SET_ADDRESS` request”. This won’t do, but we can make 0xFF
the sentinel, because real addresses are guaranteed to be less than 128.
Address state: Manage remote wakeup feature

Add another global to track whether remote wakeup is enabled or
disabled. Initialize it to disabled on startup and on reset. In the
handler for `GET_STATUS` at the Device, return current value. Handle
`SET_FEATURE` and `CLEAR_FEATURE` to set and clear this flag.

We will use this variable when actually implementing suspend and resume.
Address state: Handle `GET_STATUS` for Endpoint 0

In the Address state, we have to handle `GET_STATUS` for the
device (which we did in the last commit) and for the control endpoint.
Add another case branch in the switch by recipient in `usb_request`,
repeat dispatch by request type, then request ID, then endpoint index.
For Endpoint 0, tell we’re not halted.
Address state: Handle `{GET|SET}_CONFIGURATION`

Lastly, let’s handle `SET_CONFIGURATION` and `GET_CONFIGURATION`. Add
another global for the currently selected configuration. Initialize to 0
on startup, reset and address assignment. For `GET_CONFIGURATION`,
return the current value. For `SET_CONFIGURATION`, check the requested
value’s range, store it, and transition to either Address or Configured
state.
## Address state: Conclusion

After these changes, both USB state LEDs light up (indicating
`state_configured`) and the output in the system log changes to:

```
[581500.932158] usb 2-3.1: new full-speed USB device number 20 using ehci-pci
[581501.042287] usb 2-3.1: New USB device found, idVendor=0e6a, idProduct=030d
[581501.042293] usb 2-3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[581501.044657] usbhid 2-3.1:1.0: can't add hid device: -32
[581501.044671] usbhid: probe of 2-3.1:1.0 failed with error -32
```

Here, the generic usb driver got from us everything it wanted to know,
it assigned us an address, and it configured us into our first (and
only) configuration. Now it calls up the class driver `usbhid`: “Here,
you deal with this one”. And now that we are in the Configured state, we
have to face several more requests that we don’t yet handle.