Firmware: Move driver instances into driver implementation files

[antoinevg]

This PR moves driver instances out of a central drivers.x file and into the individual driver implementation files.

This shift is to reduce linker coupling that would result in unnecessary inclusion of symbols from firmware/common/ in HackRF firmware other than hackrf_usb.

As per conversation at: #1709 (comment)

[martinling]

From an integration point of view this is a good improvement and gets rid of most of the awkward legacy of hackrf_core being a module that depends on everything else in the tree.

Looking a bit beyond the scope of this PR, there is still a bit of a problem with pins.c depending on things that it doesn't really need to, because of code in pins_setup which writes to ssp_config_max283x, ssp_config_max5864, sgpio_config, ssp_config_w25q80bv, spi_flash, etc. Much of that initialization code doesn't need to be part of pins_setup - it could move into init/setup functions within the driver files that now own those structures.

[antoinevg]

Looking a bit beyond the scope of this PR, there is still a bit of a problem with pins.c depending on things that it doesn't really need to, because of code in pins_setup which writes to ssp_config_max283x, ssp_config_max5864, sgpio_config, ssp_config_w25q80bv, spi_flash, etc. Much of that initialization code doesn't need to be part of pins_setup - it could move into init/setup functions within the driver files that now own those structures.

💯 -- this is one of the things I've been looking at in my carcinization branch. Tight-coupling is a blessing for readability when there is complex, inter-dependent configuration steps but most of pins_setup() really is just boilerplate that doesn't need to be right in your face.

[mossmann]

Nice! Thank you!