Add persistent alerts API

[jwbonner]

Related to #6573. This is a version of the 6328 Alert class, which is already compatible with Elastic and FWC (and soon Shuffleboard). The expected usage is described in the class Javadocs. This API is intended only for alerts which can be declared at startup and activated/deactivated as necessary. Other use cases (i.e. alerts that are periodic or non-persistent) should be handled through other channels, like console logging.

NT publishing is handled internally via a private Sendable class, which is different than the traditional usage of Sendable. The idea is to minimize the setup required for declaring new alerts (i.e. manually publishing alerts/groups via the SmartDashboard API is unnecessary when adding a new alert).

[TheTripleV]

What do other libraries use for alert types? Not that it's a robotics library but sphinx/docutils uses

"attention", "caution", "danger", "error", "hint", "important", "note", "tip", "warning"

for admonitions.

Python's logging's default levels are

debug, info, warning, error, critical

[PeterJohnson]

This can be done as a second step, but we need to add hooks into the HAL for this so vendors can use it.

[jwbonner]

I think more thought is required in regard to how vendors should integrate with this system. One of the main benefits this system provides is that users can be selective about surfacing only the most important and useful information, with expressive descriptions that are specific to their robot, subsystems, and objectives. My concern is that automatically generated vendor alerts (i.e. "Missing status frames from Device X") will cause clutter and prevent users from making the most of the alerts system.

My recommendation would be to have vendors (and WPILib) use one or more non-default groups (either a generic "Vendors" group or one for each vendor), which would be reflected in the HAL API. Those groups could still be auto-populated on dashboards, but wouldn't interfere with user alerts. Vendors should also have fault APIs (many already do) which users can utilize to create more useful and expressive alerts in the default group.

As an aside, if the primary purpose of vendor level alerts would be to show disconnected devices, I could also see creating a widget specifically designed for that purpose (like a status panel of a vendor's devices).