update fork

update fork

…rruption, and ending

…roup)

Originally, PIDController used PIDSource with its "PIDSourceType" to
determine whether a class should return position or velocity to the
controller. However, the supported languages have changed a lot over 10
years and now support lambdas. Instead of using PIDSource and PIDOutput,
I propose making PIDController take lambdas for the measurements and
outputs. This makes the controller much more flexible for team's needs,
and Java's method references make specifying them trivial. Teams no
longer have to make a separate PIDSource-inheriting class just to
provide a custom function. Java supports anonymous inner classes to
mitigate this, but C++ has no such thing and is much worse off without
lambdas.

The built-in feedforward is now also a lambda. It's easier for the user
to specify the feedforward they want whether that's just a constant or
a Kv/Ka feedforward than have PIDController shoehorn a specific one into
the implementation that the user then has to work around. The advice
"just inherit from PIDController and do your own" requires more work and
is inconvenient for such a simple user-level change.

To facilitate running the controller synchronously, there is a
ControllerRunner class that handles that. By separating the loop from
the control law, PIDController can now be composed with others and be
used to control a drivetrain (a multiple input, multiple output system
that requires summing the results from two controllers) much easier.
Also, motion profiling can be used to set the reference over time.

The term setpoint was replaced with reference because the latter is used
in all other fields of control theory. PID control is the exception
here, and I thought it would be best to use the term reference so
students learn to use the right terminology if they advance further in
their controls education.

All the classes related to the old PIDController are now deprecated. The
old classes were prefixed with "Old" so users can make their code use
that for the deprecation period. This was necessary to eliminate ODR
violations in C++. It was done in Java too for consistency.

While this is a large change, I think it is a necessary one for growth.
The old PIDController design was created in a time when languages only
supported OOP, and we have more tools at our disposal now to solve
problems. This more versatile implementation can be used in more places
like as a replacement for Pathfinder's "EncoderFollower" class.

There has been hesitation to add lambda support to WPILib for a while
now out of concerns for requiring teams to learn more features of C++ or
Java. In my opinion, this change makes PIDController easier to use, not
harder. The concept of a function is a building block of OOP and should
be learned before classes. The ability to store functions as first-class
objects and invoke them just like variables rather natural.

Note that PID constants for the new controller will be different from
the old one. The original controller didn't take the discretization
period into account. To fix this, teams should just have to divide their
Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the
original default period.

…commands, add default no-op implementation of remaining Command methods

…se, rename accordingly

…ommandBase