Warn when PIDController.calculate() is called without a set setpoint

[pusheeeeeeeen]

Is your feature request related to a problem? Please describe.
I was recently refactoring some code using a PIDController, and ended up (intentionally) removing a call to setSetpoint(). However, I forgot to update the call to calculate() to use the two-argument overload with a setpoint, meaning that it was calculating based on the default setpoint of 0.0.

Describe the solution you'd like
Print a warning or error if the one-argument overload for calculate() is called before a setpoint has been set, making use of the existing m_haveSetpoint field.

[Gold856]

Would it be better if we removed the one-argument overload? I feel like it would be clearer a lot of the time if you always had to pass the setpoint to calculate, since if you have a PIDController already, you can just... call calculate instead of setSetpoint, although I can imagine scenarios where those two might be separate (but that still means some spooky action at a distance).

[calcmogul]

I always use the two-arg overload, but that's because I always use a motion profile with my feedback controllers. Teams can potentially set-and-forget their setpoints and use the one-arg overload instead, but I don't know how common that is.

Removing the one-arg calculate() overload would also make setSetpoint() redundant. We'd ideally propagate the change to all the other controllers for consistency.

[sciencewhiz]

Teams can potentially set-and-forget their setpoints and use the one-arg overload instead, but I don't know how common that is.

I suspect it's relatively common, with setpoint being set in a command and calculate being called in a subsystem periodic method.