When a pipe is closed, clear the memory of the corresponding enpoint
context, not the whole array of endpoints.  Yeah, pointers are hard.

Fix a panic reported by Dimitris Papastamos on tech@
Remove USB locators.  They are currently unused and this wont change due
to the way USB buses are discovered.
Apparently xhci(4) also needs a hook to set the address of a device.

Some Low/Full speed devices do not like to get a SET_ADDRESS command
before we have read (some bits of) their device descriptor.  So change
the attach logic to issue two "Device Address" command with a BSR dance.

This should fix the "device problem, disabling port" error seen on root
hubs with some Low/Full speed devices, reported by miod@.
Add some fields needed for TT support.
Support USB 1.x devices below external hubs.

This code is violating various layers of abstraction, just like ehci(4)
does.  Transaction translators need a bit more love.
Do not reset the base address of the control endpoint's ring when
the second "Set Address" command is issued.  This would lead the
HC to reprocess TRBs corresponding to completed transfers.

This was the cause of the "xhci0: NULL xfer pointer" message that
could be seen after attaching a device and reported by naddy@.
When a bus is explored, do not probe the ports which status hasn't
changed.  This saves a lot of I/O when attaching/detaching devices
and might help with some timing related problems.

Has been in snap for ten days, committing now so that people testing
xhci(4) test the same thing w/ snapshots and their own kernel.
Two fixes to make Qemu and VMware xHCI implementations work:

1. Always unmask the slot context for the "Set Address" command.

2. Use the right spl when submitting a transfer to prevent from
   setting up a timer on an already completed xfer.

Analyzed with and ok jsg@