Add getPath method to SendableBuilder

[Gold856]

Designed to be equivalent to NTSendable's getTopic, but backend agnostic. It returns a string representation of the path where the properties will be placed, e.g. /Epochs/Scheduler or /SmartDashboard/Scheduler/Epochs. This allows for topics to be dynamically created. The implementing class would call getPath in initSendable and store the path in a member variable (actually two, one for NT and another for DataLog), and would use it with NT publishers and DataLog to publish values. It would be up to the implementing class to support all backends (I don't think delegating dynamic topics to SendableBuilder is the right path). Unblocks #5375.

[PeterJohnson]

The point of Sendable/SendableBuilder is so that implementing classes don't need to know the backend. For example, wpimath classes cannot directly access the NT backend, because wpimath does not depend on ntcore. NTSendable exists so that the classes that do need that feature have a way to do so.

Sendable also allows for arbitrary placement (and even multiple placement, although some classes break this ability, particularly NTSendable-using classes).

[Gold856]

Maybe SendableBuilder could accept a lambda returning a Map<String, T>, where T is a type supported by SendableBuilder. When the builder is updated, it takes each map entry and publishes each with the string key as the topic name, and the value as the value. The implementing class doesn't need to know the backend, it just has to provide a map.

This doesn't solve Tracer's problem where it can't capture the timing of SmartDashboard.updateValues, but Tracer probably needs its own solution. This generally solves the problem of dynamic topics.