Implement update frequency tiers for cycles

Some metric providers may interact with components that have a variety of metric types. Some of these metrics may be static, others may update once every minute, even more may be expected to update every tick. The current design treats all metrics the same, updating every metric during every cycle.

If an input adapter tightly integrates with its components (such as the Mekanism input adapters), it is fair to say there would be established knowledge on which metrics update "fast" and "slow".

The Backplane could be configured to support several cycle speeds, prioritizing certain inputs to be read more often than others in the same period of time. Input adapters themselves could define their APIs in such a way to divide the metrics into groups, like "fast", "slow", and "static". These groups would have default cycle times, but could be overridden by a user.

However, this introduces a challenge with how the Output Adapters should behave. Some output adapters may not benefit from accelerated update times, or cause confusing/corrupted results. Other outputs would greatly benefit, such as charts and other visual indicators.

This issue will serve as a place to record ideas during the planning of this feature.

Start by reviewing the Backplane cycle design and the APIs for input adapters, including the Mekanism input adapters mentioned in the issue. Compare how fast, slow, and static metric groups could affect output adapters, especially charts and other visual indicators. Done means an agreed design for configurable cycle tiers and compatible output behavior.