Improving MSP spec and API generation

[xznhj8129]

So i did the big work of parsing all the MSP used by INAV and then some with the MSP documentation, documenting every possible message and used enum into a JSON spec file. https://github.com/iNavFlight/inav/tree/master/docs/development/msp

It's very imperfect and uses some questionnable practices to parse all of the enums and defines used by the messages which may not always correspond to the build depending on the options, there's no versioning or history, little detail on what messages actually do (ie: how to get the programmed modes using MSP_BOXIDS and MSP_MODE_RANGES), enums are named but not actually defined and so on. JSON is also maybe not the best format for this, i chose it just out of familiarity. The hard part was gathering and validating everything, the rest is relatively easy.

The main interest is not only having a far easier time developing, generating and maintaining documentation and debugging; which is already a huge boost; but also the possibility of having a unified, official, definitive MSP Source Development Kit that provides an API for Python, C, Arduino, Javascript, etc... replacing all of the dozens of unfinished projects or hardcoded implementations you can find for each of those. The single source of truth would be in the official repository, generated at every change, versioned, clean and proper. It wouldn't be too far off from the level of development-friendliness that MAVLink currently enjoys.

I'm not a professional at those levels of development so i'm asking to see if anyone has ideas for how to improve the spec, generation and the rest. I do have a basic python API (using runtime class attritube loading from the JSON) as well as a basic Arduino API (based off the older MSP-Arduino, using C headers generated from the json); but i'm not at a seamless generation level yet; as well as being swamped in other work.