[wpimath] Add ChassisAccelerations and drivetrain accelerations classes and add forward and inverse kinematics for accelerations to the interface

[zachwaffle4]

ChassisAccelerations and the drivetrain acceleration types are added in both Java and C++. ChassisAccelerations is basically just ChassisSpeeds but for accelerations! DifferentialDriveWheelAccelerations, MecanumDriveWheelAccelerations, and SwerveModuleAccelerations are the acceleration equivalent of the drivetrain speeds types.

In Java, the Kinematics interface now has an additional generic parameter A which represents the accelerations, and toChassisAccelerations and toWheelAccelerations methods, which are implemented the same way as toChassisSpeeds and toWheelSpeeds.

Protobuf and struct classes were also added for all four classes in Java and C++.

[KangarooKoala]

Do we need to include adding interpolate() to the wheel speeds classes (and wheel accelerations classes) in this PR? It's already pretty large and doesn't seem directly related.

[zachwaffle4]

I included the interpolation here solely because it was also something I wanted to add and I didn't want to make another PR

[KangarooKoala]

Where's the derivation of the swerve drive kinematics math again?

[KangarooKoala]

Great work! The first PRs always take the longest (and this one is already a really large change)- Thanks for sticking with it!

[KangarooKoala]

This isn't super important, but if we're going to end up making changes anyways, could you prevent this single awkward word? (One thing you could do is to briefly join the entire paragraph into one line and then format)

If this would be the only remaining change, it's probably fine to mark this as resolved and then someone can spin off another PR to fix this.

[KangarooKoala]

Pity this didn't fit, it'd have been really nice if it did. If there's already changes to make that aren't just comment formatting, maybe try this?

Suggested change

	// FL (12, 12): radius angle = 135°, tangential = 45°, centripetal = -135° → total angle =
	// -144°
	// FR (12, -12): radius angle = 45°, tangential = -45°, centripetal = -135° → total angle =
	// 126°
	// BL (-12, 12): radius angle = 135°, tangential = 45°, centripetal = 45° → total angle =
	// -54°
	// BR (-12, -12): radius angle = -45°, tangential = 45°, centripetal = 135° → total angle =
	// 36°
	// FL (12, 12): radius angle = 135°, tangential = 45°, centripetal = -135°
	// → total angle = -144°
	// FR (12, -12): radius angle = 45°, tangential = -45°, centripetal = -135°
	// → total angle = 126°
	// BL (-12, 12): radius angle = 135°, tangential = 45°, centripetal = 45°
	// → total angle = -54°
	// BR (-12, -12): radius angle = -45°, tangential = 45°, centripetal = 135°
	// → total angle = 36°

Up to you how you want to format it, this is just a suggestion.

[KangarooKoala]

Could the tolerances be changed from 0.1 to kEpsilon? I'm not sure why some of the other tests use 0.1 instead of kEpsilon, but it'd be good to specify a higher level of tolerance.

[KangarooKoala]

Does lowering the alpha tolerance in testTurnInPlaceForwardAccelerations work locally?

[KangarooKoala]

Hm, not sure why the formatting got so messed up.

[KangarooKoala]

CI failures:

• The Bazel Mac failure, Bazel Windows (arm) failure, and Bazel Windows (native) failure just need an @SuppressWarnings, since we do want to write the test in that way.
• The wpiformat failure shows a diff that you can manually apply, and it uploads an artifact containing a patch file you can apply.
• The javaformat failure will require running ./gradlew wpimath:spotlessApply.
• The Cmake Windows failure is an intermittent network failure, so we'll just see how it goes after fixing the other issues.