[api] Create a common API for accessing device file data

[salkinium]

This is the initial exploration of what a shared API for accessing device file data could look like.
The goal is to decouple the device file data from the underlying format, and to move common algorithms for computing implicit data out of the using library (here modm modules) into modm-devices and to create a proper documented and versioned Python API.

Note: This is all very experimental, even if the technical side of this (ie. moving code) is simple, everything around it (docs, versioning, hosting) is not.

TODO:

• GPIO driver
• Core driver
• Dma driver
• Common driver base class for all other basic classes, incl. features and instances access
• Documentation of the whole API via docstrings
• Hosting documentation on data.modm.io and local docs
• Move DeviceFile Cache from modm to here
• Explore how to do proper API versioning
• Device file consistency checks
  • Every GPIO signal must have a driver and name key
  • GPIO signals must be unique

cc @rleh @chris-durand @strongly-typed @mikewolfram @dergraaf

[salkinium]

I found data inconsistency due to the merge algorithm. Hmpf.

[mikewolfram]

I found data inconsistency due to the merge algorithm. Hmpf.

This leads me to a question. I've found that some hardware, which has several instances on one STM32, the instances are named xxx1, xxx2 etc. But if there is a variant of the STM32 which has a single instance only, sometimes that instance is simply named xxx. Wouldn't it be better, to also name the single instance xxx1?

Example: F303K8 has a single CAN.

[salkinium]

Define "better". If ST fails at properly enumerating their peripherals, it becomes difficult to fix this, because this naming is then used in all docs and also in the CMSIS headers (although not consistently 🙄).

I'm currently delegating formatting to the HAL library, which may decide to rename instance "" to "1". In general we try to use the datasheet definitions though.