Allow deployment FPP files to filter non-needed channels

[bevinduckett]

Telemetry channel usage currently places a constraint on component reusability in F´.
Each channel update done by calling tlmWrite_<channel>() has a CPU cost (getting time stamp + serialization + storage into tlm DB) cost; and the telemetry DB implementation for TlmChan & TlmPacketizer both have a per channel memory cost (even for ignored ones in TlmPacketizer).

This creates a tradeoff:

• If a component reports too many channels, projects will be pushed to do clone-and-own due to performance concerns.
• If a component reports too few channels, projects will be pushed to do clone-and-own to gain sufficient observability.

It seems like components in fprime are leaning towards very minimalist channelized telemetry for that reason.

Example: Svc.CmdDispatcher

It's currently reporting three channels:
- Number of commands dispatched
- Number of command errors
- Number of sequence cmd buffers drop

But there's quite a few other channels it would be useful for CmdDispatcher to report:
- Number of immediate commands received, dispatched, completed successfully, failed due to de-serialization error, failed due to invalid opcode, failed due to arg validation error, failed due to execution error
- Same counter channels for sequence commands
- Opcode & time of the last command dispatched, last succeeded, last failed, (for immediate & sequence)
- Number of in progress commands & number dropped due to the table being full
- Number of in progress sequence command buffers

Proposal
Add a feature so that a deployment's FPP file (or another deployment-specific configuration file) could specify a list of channels to disable and have the FPP autocoder do the following for each:

1. Generate an empty function for the "tlmWrite_()" helper function (allows compiler optimization to inline and eliminate the call)
2. Exclude the channel from the channel/telemetry dictionary
3. Don't define an ID for that channel (for compile-time detection if a disabled channel ID is in a packet definition for TelemetryPacketizer)

[SterlingPeet]

@LeStarch this sounds like the system we talked about at smallsat 20 or 3 years ago. My use case was a little wider, allowing for removing unused ports from the system model as well.

For context, my desire was/is driven by wanting support a real topology full of trimmed-but-standard component that fit on extremely small platforms. Platforms with less than 256k of memory, like the ATMega128 or the SAMD21 parts. Super low footprint, super low power, full F Prime framework support.

This sort of thing is highly useful for ultra-low SWaP situations, like safe-mode operations in 1U-3U cubesats. Or in small-scale low-speed space tranceivers.

[celskeggs]

I think this is a great idea. See also #4007, which is a similar request for commands. In the long term, we probably want a general configuration mechanism that allows FPP definitions to be adjusted on a per-project basis.