I2C Overhaul, Dependency Removal, and Peripheral Manager Redux

[mikepparks]

I2C Overhaul

This moves configuration of I2C controller blocks to a global scope, instead of a per-addon scope.

• All functionality currently using I2C (Display, ADS1219, and Wii) has been updated to only require a controller block option, and in certain cases, a device address (Wii extension addresses are not selectable so it is exempt).
• If no I2C block has been enabled and configured, I2C functionality will be disabled and affected functionality will display a message.

Dependency Removal

This also removes a dependency on the BitBangI2C library that existed in name only and wrapped pico-sdk functionality. It has been replaced with a library developed for the project called PicoPeripherals that will handle core peripheral functionality (initialization, reads, writes, etc.).

Peripheral Manager

To round out the changes to I2C, a Peripheral Manager has been introduced. This manager was written to leverage on-chip peripheral devices as needs arise. In addition to I2C, SPI has been added to this manager, but no functionality currently leverages it.

• Peripheral Manager handles the global configuration scope of I2C and SPI devices, and initializes them if the respective devices have been enabled.
• Each device is initialized as a singleton, so there can only ever be reference to one interface per controller block. With I2C in mind, this reduces the need to initialize devices or change options, which could disrupt functionality.

[dogtopus]

Since I2C and SPI access are now encapsulated, it would also make sense to take this opportunity to allow proper peripheral sharing across cores. Adding a recursive lock and methods to allow exclusive access for multiple read/write transactions (e.g. i2c.grab() and i2c.release()) would probably be enough.

[mikepparks]

@dogtopus I do agree, but the first iteration of this is to get the new structure in place, and make sure that it doesn't break things in the process. Optimizations will come in a later PR, as there's some work that I would like to do to the Display functionality to clean things up. Right now, I'm assessing options for that part, which could mean ditching the OneBitDisplay library entirely, but it's a bit too early for me to tell. Display is the culprit for a lot of our I2C collisions, and likely the reason why things do not play nice across cores.

[arntsonl]

Looks fantastic, thank you for all the hard work!