[wpimath] Remove swerve wrappers for odometry and pose estimation, move wheel positions operations to kinematics

[KangarooKoala]

By moving the wheel positions operations to kinematics, we can remove the need to declare methods on the type parameters, which allows us to use arrays as the type parameters.

I'm open to splitting this into multiple PRs or deprecating SwerveDriveWheelPositions and SwerveDriveWheelStates/SwerveDriveWheelSpeeds until after the next season, but I'm starting with a large PR first to show the overall plan.

Notes:

• Breaking changes: The potentially breaking changes are 1) adding methods to Kinematics that custom implementations must implement and 2) removing SwerveDriveWheelPositions and SwerveDriveWheelStates/SwerveDriveWheelSpeeds (apparently they have different names in Java and C++) and the methods using them in SwerveDriveKinematics, SwerveDriveOdometry, and SwerveDrivePoseEstimator. The first category only affects those with custom kinematics implementations, and I personally am fine with breaking them, given that only advanced users would have a custom Kinematics implementation, given the warning in the second sentence of the doc comment and the fact that the class is only 1 year old. The second category should also affect only a small subset of teams (Those classes are not meant for direct team use, but some teams may get confused), but I could see the case for deprecating first and then removing.
• Motivation: This reduces the surface area of the library, but also reduces memory allocations by saving on an intermediate object and more importantly, excessive copies. The copies could likely be avoided by making the classes not copy the array at all (and instead rely on using copy() to avoid mutation issues), but since this also cleans up the library a bit, I figured I might as well do this instead.
• C++ interpolator: C++ does not have an interpolator class- Instead, it uses std::function<T(const T&, const T&, double)> or a combination of addition, subtraction, and scalar multiplication operators- so there is not a preexisting class with virtual methods for Kinematics to inherit from.
• Documentation changes: Some of the methods have minor docs changes because the doc comment on the base class did not exactly match the previous doc comment. I don't think there are any major disparities (The biggest difference seemed to be a sentence or two), but the zealous may want to double check the changes.
• @SuppressWarnings("overrides"): This suppresses a warning about overriding a non-varargs method with a varargs method. (In this case, toChassisSpeeds(SwerveModuleState...) overriding toChassisSpeeds(P) where P is SwerveModuleState[]) For reason, although annotating the specific method works when the overriden method is specified in a class, the annotation must be applied to the entire subclass when the overriden method is specified in an interface (or an abstract class).

[KangarooKoala]

The CI failure seems to be from an unrelated test?