Allow unsetting a subsystem's default command

[democat3457]

Changes the behavior so calling setDefaultCommand(subsystem, null) unsets the default command of subsystem. I realize that calling register on the subsystem does the same thing, but this behavior is more explicit and intuitive.

I don't know how to do the C++ translation...

[rzblue]

I don't think this is how we should handle this. Currently the semantics of changing a Subsystem's default command aren't clearly defined, and shouldn't be relied upon.

Additionally, I don't think calling register on a Subsystem should do remove a subsystems default command; Perhaps that should be changed.

[democat3457]

a) Would you suggest adding a new removeDefaultCommand(Subsystem) method instead?

b) That seems like that would require a whole rework of the default command and subsystem registration system...

[Starlight220]

A remove method would be better, because we want the null check to catch cases where teams accidentally pass null.

Subsystems should be mostly RAII; re-registering them (especially without calling unregister) doesn't have defined semantics and we should probably check and throw on it.

---

As mentioned, default commands in their current form fall under configuration, and shouldn't be set more than once.
However, now that we've added better support for swapping trigger bindings, I can see why there's a need to swap default commands as well.

For a while I've been thinking of demystifying default commands and refactoring them into Trigger bindings, basically adding syntax sugar around the following:

new Trigger(subsystem.requiring() == null, loop).onTrue(command)

This should help a bit with clarifying semantics and when default commands can be changed.
Thoughts?

[rzblue]

new Trigger(subsystem.requiring() == null, loop).onTrue(command)

I think that might help solve some of the problems and resolve some of the semantics. Is that something we can target for this season?

If not, I think we should check if the subsystem is already registered, and either noop or throw an exception. I'd vote for no-op, as the documentation does not state that register explicitly sets a null default command, and only stipulates that the subsystem will then have it's periodic methods called. I don't think that innocently calling register on a subsystem that's already registered is worth throwing over.

[Starlight220]

I think that might help solve some of the problems and resolve some of the semantics. Is that something we can target for this season?

I can try to write up a PR this week.

[Starlight220]

Needs a unit test and C++.