ESC Flasher module for AM32 firmware flashing

[MattKow-Firefly]

Solved Problem

This PR contains some ESC flashing capabilities that Firefly has been using to flash AM32 firmware.
It needs to interface with DShot and DShot Telemetry code, in order to bring the ESCs into bootloader. Then it uses the same DShot signal line to perform bit-banging.

[MattKow-Firefly]

I'll add some explanation here:
I work for Firefly Drone Shows, and we have thousands of quadrotor drones. We used to use BLHeli firmware on the ESCs, but since that was discontinued we switched to AM32 a while back. To reprogram our old drones that have BLHeli, we need to take them apart and manually reflash the ESC micros with a debugger. Now working with AM32, we find that we are adjusting the ESC settings. This also required getting the drones in, and taking the plastic covers off, connecting a separate Flight Controller to a connector, and using the AM32.ca website to reconfigure. My project was to add AM32 re-flashing capabilities straight to our PX4 custom fork.
The end result, that we have been using for a few months now with success, is an ESC Flasher module that ties in with the DShot driver and DShot Telemetry parser. The ESC Flasher module can be started/used by NSH or by setting a few parameters. When needed, it sends uOrb messages to the DShot driver, then takes over the GPIO signal line and uses bit-banging to talk to the AM32 bootloader. We have the esc_info command working through DShot, and the reflashing just flashes a const binary buffer (AM32firmware.c). The binary buffer contains the new firmware for the AM32 ESC, with our new settings hard-coded, which we could do because AM32 is open-source.
We did not yet do the PX4 passthrough ESC to USB, which would have allowed for changing settings on the fly. So please do not expect to use AM32Firmware.c on ANYTHING ELSE! It is custom with our locked settings and version and name, and will not be ideal for anything else. But obviously it can be replaced.