Add `DeferredCommand` for commands that need runtime construction

[Oblarg]

This would work similarly to ProxyCommand except it would not expose the wrapped command to the scheduler, making it more suitable for composition inside of single-subsystem command groups (ProxyCommand is designed for forking off to an unrelated requirement, and the semantics there are not well-suited to deferred execution inside of an ordinary composition).

A deferred() factory method should be added, as well.

[Starlight220]

We had this problem with SelectCommand, which is why we moved the deferred functionality to ProxyCommand: when the command's construction is deferred, there's no way to figure out requirements etc. Hence, deferred are proxied.

[Oblarg]

DeferredCommand would declare its requirements normally, and because it would wrap the supplied command internally it would sidestep the current problem ProxyCommand has with the proxied command's requirements possibly conflicting with those of the group it's composed in.

[Starlight220]

That requires duplicate declaration of requirements, which is easy to miss.

[Oblarg]

Not if we use subsystem factories to do the requirements implicitly.

[Starlight220]

Not really... in my experience, most of the cases for deferred command construction is for multi-requirement commands.

[Oblarg]

I've seen a bunch of teams using it to do runtime state dependencies in their commands (e.g. generating a trajectory and then following it), which seems like a reasonable case that we should support in a way that handles the requirements correctly "by default." Currently we don't.