Expose channel monitoring and telemetry as RTIC tasks

[ryan-summers]

This PR closes #5 by exposing the channel management interface as two RTIC tasks. Namely, there is a telemetry task and a monitor task.

The monitor task runs at 50Hz and detects errors/warnings/enabled state of the channel to propagate the user interface LEDs.

The telemetry task runs at 2Hz to report detailed channel measurements over a telemetry interface for reporting.

Currently, the scheduling is accomplished using hardware timers. We could go for RTIC monotonic implementation to use a single timer resource in the future, but I figured it was fine to use the timer interrupts for now.

[jordens]

• HW timers are certainly fine for now. But ultimately with the other timer based operations (like the MQTT state machine, networking), it needs to be the RTIC timer queue.
• The description of the fast task should probably "things we need to react to relatively quickly": buttons, interlock/alarm detection, and global veto (PGOOD etc)

[ryan-summers]

I've updated this to use the RTIC CYCCNT. We can replace the scheduler with our own monotonic in the future, such as something from embedded-time.

I dislike the current implementation because it relies on a hard-coded constant CPU clock and doesn't allow the device to enter low power states when the clock is not in use.

I've also updated this branch to use an alpha release of shared-bus, which adds a lot more flexibility to shared-bus.

[ryan-summers]

Using our own fork beause I've made a number of ADC and I2C related patches that are required for our operation. Most are merged in to the stm32f4xx-hal mainline, but there's some that aren't quite there yet.