This was developed in conjunction with #7780 to provide support for nimble BLE on windows to the unix port.

This allows a usb/serial HCI controller to be used on windows to test and run bluetooth micropython code.

This has only been added to minwg / make based builds at this stage. The MSVC project has not been updated to match.
I suspect nimble builds may not be possible with MSVC due to a struct size issue that took quite a long time to debug.

Nimble uses struct size to test whether the correct HCI packet has been received, eg.

struct ble_hci_ev_command_complete {
    uint8_t  num_packets;
    uint16_t opcode;
    uint8_t  status;
    uint8_t  return_params[0];
} __attribute__((packed));

...

ble_hs_hci_rx_cmd_complete(const void *data, int len,
                           struct ble_hs_hci_ack *out_ack)
{
    const struct ble_hci_ev_command_complete *ev = data;
    const struct ble_hci_ev_command_complete_nop *nop = data;
    uint16_t opcode;

    if (len < sizeof(*ev)) {
        if (len < sizeof(*nop)) {
            return BLE_HS_ECONTROLLER;
        }
...

On linux/unix/arm builds sizeof(struct ble_hci_ev_command_complete) == 4 as the uint8_t return_params[0]; is essentially ignored.

On MSVC apparently this null array is apparently included as size 1, eg. sizeof(struct ble_hci_ev_command_complete) == 5 - and by default mingw matches MSVC behavior on this. This was causing the code above to return BLE_HS_ECONTROLLER error instead of correctly processing the hci packet.

I had to add the compiler flag -mno-ms-bitfields to make mingw match "regular" gcc behavior - I don't know if a similar compile flag exists to make MSVC match gcc packed struct size - let alone whether the rest of the nimble codebase is at all compilable under msvc.