Add DataLogs for More WpiLib Data

[scarmain]

Is your feature request related to a problem? Please describe.
More loggers would be really convenient for advanced logging of the robot. Some that would be easily possible as the data has functions to get the data:

• PDP - currents of all the channels, input voltage, total current, and faults (bonus points if we can name the PDP channels so we don't have to look up a schematic to know the device connected)
• roboRio - CAN status data from RobotController.getCANStatus(), Rio 3.3, 5, and 6V current and voltage.
• System Timings - The epochs logged in IterativeRobotBase.loopFunc()'s m_watchdog (and you guys are missing timing data for the DriverStation packet processing and the NetworkTables flush, more bonus points if we could get the time between driver station packets) Some things like the other background thread timing would be nice too (like the datalog or any custom notifiers)
• CommandScheduler - Same as system timing, but with it's internal watchdog. Also, maybe log active command list and/or events when commands start/interrupt/end
• System Usage (tough, maybe out of scope) - Things like CPU usage, IO usage, Memory Used, Network Traffic, stuff logged from Linux that could be useful

All the bonus points if we can get the signals with NetworkTables4 units that make sense with them (like timings in ms, currents in A, etc)

Describe the solution you'd like
More loggers that could be called like DriverStation.startDataLog(log);.

Describe alternatives you've considered
We did this logging this year, but it seemed inefficient putting all the data on SmartDashboard variables. Some things like the motor currents poll the PDP every request, and we would constantly get CAN timeouts for the data (after slowing logging to 100ms). These would be better to update the data every time the Rio gets the currents frame from the PDP instead.

Here was our logging framework, it won't be super relevant for pure WpiLib data, but you can see what we did. It would be great to get the data from the other CAN devices, but those are 3rd party and out of scope here ;)
Logger.java

I feel weird posting the loop time data we got this year, as we did some 'dirty' tricks to get the data this season. We used Java's reflection to get the private Watchdogs, then their private Epoch variables to finally read them. We scheduled it as a SmartDashboard.postListenerTask() so that we were able to get the timing values after the full code ran. I'm sure poking around watchdogs is not the safest thing to be doing...
LoopTimeLogger.java

Additional context
none

[Starlight220]

I agree we need a solution for this, though coupling would be a problem -- we don't need another class that is depended on from everywhere (looking at you, Sendable).
Unifying telemetry and logging would also be great.