Feature/adc api update

[finger563]

Description

• Updated continuous adc to allow user to start/stop adc (instead of only being called in constructor/destructor)
• Updated example to test starting/stopping of adc
• Updated continuous adc to convert config struct into id so that there are no possible collisions between channels (e.g. if we wanted to read channel 0 from both ADC1 and ADC2 at the same time)
• Updated continuous adc and oneshot adc to take AdcConfig as input argument for reading channel information instead of just the adc_channel_t which could collide
• Updated examples that used adc to use new APIs (controller, joystick, thermistor)
• Updated ads1x15 component to add missing pthread requirement for thread sleeping
• Updated AdcConfig to support equality operators (for use with the std::find that we use)
• Updated AdcConfig to support printing with libfmt
• Rebuilt docs

Motivation and Context

Previously, the ContinuousAdc had a possibility of collision in the data storage it used for values and filtering stemming from the use of adc_channel_t as the key (and as the input argument to the relevant functions. On the OneshotAdc such an API made sense because the oneshot adc hardware that it wraps can only be configured for a single adc unit at a time, however the continuous adc hardware supports reading from many channels across adc units. In this case, if the user wanted to read from the same channel ID (e.g. ADC_CHANNEL_0) on both ADC_UNIT_1 and ADC_UNIT_2, there would be a collision because there would be no way to distinguish the channel on the two units. By using our existing AdcConfig structure which contains both the channel and the unit ids, we can resolve this collision. This required an update to the APIs (changing from adc_channel_t to AdcConfig as well as to the data storage used.

Additionally, if the user wanted to manually start/stop the continuous adc hardware, they could not without constructing and destructing the ContinuousAdc objects. To make it easier and more useful to developers, this functionality has been broken out into start() and stop() methods on the ContinuousAdc object. If the user tries to read information about an adc channel while it is stopped, the methods will return std::nullopt.

How has this been tested?

• Building and running theadc example
• Building the controller example
• Building the joystick example
• Building the thermistor example

Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Hardware (schematic, board, system design) change
• Software change

Checklist:

• My change requires a change to the documentation.
• I have added / updated the documentation related to this change via either README or WIKI

Software

• I have added tests to cover my changes.
• I have updated the .github/workflows/build.yml file to add my new test to the automated cloud build github action.
• All new and existing tests passed.
• My code follows the code style of this project.