Check USB host connection and fall back to OTA DFU if there is none

[avg-I]

Is your feature request related to a problem? Please describe.
This is mostly an issue for boards like Pro Micro that lack physical buttons to control DFU mode.
On that board there seem to be only two ways to activate OTA:

• there is no valid application at all;
• an application explicitly requests OTA DFU before doing a reset.

Describe the solution you'd like
The boot loader could check if the board is connected to a USB host at all.
If not, then it does not make sense to expect USB serial or UF2 DFU.
E.g., if the board is powered via a battery or a dumb charger.

I think that such an enhancement would make sense even for boards with physical buttons.

Describe alternatives you've considered

Always having to patch application, so that the right DFU mode is initiated.

Additional context

It seems that something like app_usbd_core_state_get or raw NRF_USBD->USBADDR > 0 can be used as a check.

[fkallay1]

#47 (against dev) implements this, though with a different check than the one suggested here - the
suggested one was tried first and does not hold up.

Why not a register read. USBREGSTATUS.VBUSDETECT looks like the obvious gate. Measured on a
ProMicro nRF52840, it still reads 0 this early in check_dfu_mode() and only asserts some tens of ms
later, so an early read reports "no host" even with a host attached - and the device would be sent to
BLE exactly when USB was available, which is the opposite of the intent. NRF_USBD->USBADDR > 0 has
the same problem: it cannot be true before the host has got around to addressing the device, so it
has to be waited on rather than sampled.

What #47 does instead. It brings USB up and waits for the host to actually enumerate, up to a
timeout. A host that answers keeps the device in USB DFU; if nothing answers - battery, or a charger
that pulls VBUS high with no data host - it reboots into BLE OTA. Enumeration subsumes VBUS, since
"no VBUS" and "charger only" both simply fail to enumerate, and it is re-evaluated on every boot
including a cold one, unlike anything kept in GPREGRET.

What it covers, and what it does not. The case this issue starts from - no valid application - now
tries USB DFU first and falls back to BLE OTA. That is the part which previously required patching
the application. The explicit paths (single tap, UF2, serial-only) have had an enumeration timeout all
along, so nothing new is gated there; #47 only lengthens it from 3 s to 10 s, because 3 s was not
reliably enough for a host re-enumerating after a reset. No general "is a host present" check is
added elsewhere in the bootloader - so if the hope was one gate used everywhere, this is narrower
than that.

Verified on a ProMicro nRF52840 with a J-Link, reading the settings page and GPREGRET over SWD rather
than inferring state from LED blink patterns, and on a XIAO nRF52840 Sense running a different
SoftDevice.