Telemetry Improvement

[Starlight220]

I figure we'd bring the discussions on the topic here.

There are various problems with the current situation of Sendable and its interactions with various APIs such as LiveWindow, Shuffleboard, SmartDashboard.
@Oblarg did a good job of summarizing the problems in this doc, with following discussion here.
The design doc proposes a whole new API that would replace everything, but due to Sendable being one of the most depended-on symbols, I'm hesitant to completely break it -- I think that Sendable can be improved incrementally in-place, with minimal deprecations and breaking changes. My initial work (PR: #5094) on implementing the API described in the design doc proves this: much of it is code that already exists in Sendable.

As far as I know, the main features that need to be added to Sendable are the following:

• One-time publishing of constant values: SendableBuilder: Add PublishConst methods #5158
• Nesting Sendables Add nesting functionality to Sendable #5180
• Currently everything is set as controllable, kind of like with LiveWindow on. SendableBuilder: Don't set everything as controllable #5163 should fix that. That PR also adds some LiveWindow functionality tests.
• Metadata. We would probably want to separate this between multiple types of metadata: widget selection (and properties?), layout configuration, etc.

[Oblarg]

We need to separate databinding and publishing. They're not the same thing and coupling them rigidly is a poor design.

[Starlight220]

We can add publish and subscribe variants of the add*Property methods.

[Starlight220]

A few questions about controllability: what should be the default (and any exceptions)? How should controllability work with nested sendables?

[Starlight220]

After working on the tests in #5180, maybe not-controllable-by-default isn't a good idea. Having a very upfront feature that depends on a not-very-discoverable flag isn't great.
However, I'm not sure that actuators being controllable by default is a good idea either.