Restructure Telemetry dumps and metrics

[abagali1]

Description

As the current telemetry only records basic success/error message from submodules, we should implement a more comprehensive recording system that will allow for much more debugging via the ground station.
Increasing the telemetry packet size introduces the following issues:

• How will telemetry handle and store these new metrics
  • Use the current Log and Error classes to wrap around these metrics
• Will the APRS be able to handle dumping all metrics at one time?
  • Described below

New Metric collection/reporting system

This new system includes 4 parts:

1. Telemetry
2. APRS
3. Core
4. Command Ingest

Instead of having dedicated Telemetry dumps every hour, there will be two separate processes regarding dumps:

1. Essential data will be emitted every 30 seconds
2. A large dump can be triggered through Command Ingest

Dataflow:

• A new, metric.Metric class will be created to encapsulate data.
• telemetry.enqueue will become more direct to deprecate telemetry.decide
• a metric_stack will be added to telemetry
• enqueue will directly push to these stacks
  • or call command_ingest.enqueue
• core will call telemetry.emit, similar to telemetry.dump except only specific values from metric_stack are sent over to aprs
• command_ingest will be able to call telemetry.dump, which will dump and clear all stacks through APRS
• a new method telemetry.beacon will be called every 30 seconds by core and should read(not pop) the most recent, critical metrics from the metric_stack and send those through APRS.

[abagali1]

Comment what metrics should be collected on a submodule basis.

[abagali1]

EPS:
battery voltage
battery temperature
battery current and direction