Refactor AngularVelocity/Acceleration classes

[nycrat]

Description

Instead of the AngularVelocity and AngularAcceleration literally being an alias of Angle, this PR refactors them into child classes of Angle which has a few advantages:

• As mentioned in the original issue, some methods of Angle do not make sense for AngularVelocity/Acceleration. So, we delete these methods in the child class to prevent their usage.
• While debugging, I noticed there was a lot of incorrect usage of these three classes, for example, in er_force_simulator.cpp, there is a pair defined as std::pair<Vector, Angle> which is then passed to a function that uses std::pair<Vector, AngularVelocity>. These inaccuracies do not raise any error or warning with the original aliases, but now should enforce that there is a difference between the three classes.
• In the future, we may want special functions for angle velocity or angle acceleration, so this should allow for that.

Line 7 of this code shows exactly the reason why original aliases were an issue.

Testing Done

Ran thunderscope and the tests, everything seems to be fine.

Resolved Issues

resolves #3093

Length Justification and Key Files to Review

Lots of the changes were to correct usage of Angle -> AngularVelocity in lots of files in the codebase.

Review Checklist

It is the reviewers responsibility to also make sure every item here has been covered

• Function & Class comments: All function definitions (usually in the .h file) should have a javadoc style comment at the start of them. For examples, see the functions defined in thunderbots/software/geom. Similarly, all classes should have an associated Javadoc comment explaining the purpose of the class.
• Remove all commented out code
• Remove extra print statements: for example, those just used for testing
• Resolve all TODO's: All TODO (or similar) statements should either be completed or associated with a github issue

NOTE: I'm not sure if this is the best approach, it is possible to privately inherit from Angle and then avoid the delete statements so that may be cleaner instead. But it would be necessary to redefine inherited functions such as toRadians() that just calls the parent function. It is already necessary to redefine parent functions that return Angle, so for example, we need to redefine fromRadians(rad) since the original returns an Angle, and we need it to return AngularVelocity instead.

Also I'm not sure exactly which methods should be included or not used by the angular velocity/acceleration classes.

[GrayHoang]

These comments also apply to the angular acceleration files.

[itsarune]

drive-by review, another good and valid option that I'd argue is cleaner is to declare separate AngularVocity and AngularAcceleration classes that internally hold an Angle under the hood:

class AngularAcceleration {
     int abs() {
         return angle.abs();
     }
private:
Angle angle:
}

The benefits are that you get type-safety without duplicating a lot of code and you only need to specify the functions that are relevant for the class. Inheritance doesn't really make sense here because conceptually AngularAcceleration is kinda different from an Angle.

[nycrat]

Yea maybe avoiding inheritance is the best solution, I'll see what I can do

[nycrat]

Ok this new solution uses C++ 20 concepts and abbreviated function templates to make the generic angle class much cleaner and it is easier to change the behaviours of methods for specific classes. I fixed all the type issues related to Angle and AngularVelocity so the software and simulated gameplay tests all pass now.

However, I think that the cross compiler for the jetson/raspberry pi has an outdated gcc version that doesn't completely support these c++ 20 features, not exactly sure how to fix that... apparently it comes from https://github.com/UBC-Thunderbots/Software-External-Dependencies?