Add an event in CommandScheduler before each command is executed

[rcahoon]

The new onBeforeExecute event parallels the existing onCommandExecute, but onBeforeExecute is run immediately before the execute() of each Command, whereas onCommandExecute is run immediately after. This allows for such uses as profiling the runtime of each Command, or reporting which Command is currently running.

[github-actions]

This PR modifies commands. Please open a corresponding PR in Python Commands and include a link to this PR.

[Starlight220]

Both of the use cases mentioned are already possible; I'm not sure what this improves

[rcahoon]

Both of the use cases mentioned are already possible; I'm not sure what this improves

Could you provide me some more detail about how to report the currently-executing Command without this change? I wasn't able to find a way to do that.

I would like to be able to add an assertion like this in my Subsystem:
assert CommandScheduler.getInstance().requiring(this) == MyCommandSchedulerUtils.getCurrentCommand();
to ensure that a Command must declare my Subsystem in its requirements in order to use it.

[Starlight220]

By currently-executing command do you mean the command currently being iterated on by the scheduler, and not simply currently scheduled?
Why is requiring() and (I think there's a getRunningCommands or something) not sufficient?

Ensuring requirements is more simply done via using subsystem factory methods and access control etc.

Command timings are already recorded by the scheduler tracer/watchdog; maybe there's room for improvement with exposing that data.

[rzblue]

For timing/profiling commands, see #7099

[rcahoon]

By currently-executing command do you mean the command currently being iterated on by the scheduler, and not simply currently scheduled?

Yes

Ensuring requirements is more simply done via using subsystem factory methods and access control etc.

With the Trigger/FunctionalCommand lambdas being in RobotContainer along with the Subsystems, it's very easy for someone to use a Subsystem but forget to add it to the Command's requirement list.

Defensive Programming best practice is to have the receiver, not the caller, validate preconditions.

[Starlight220]

With the Trigger/FunctionalCommand lambdas being in RobotContainer along with the Subsystems, it's very easy for someone to use a Subsystem but forget to add it to the Command's requirement list.

That's the idea behind the paradigm of subsystems' public API only consisting of command factories and reading accessors/Triggers.