Java's type system is incapable of handling these with generics, so we need to write all the discrete cases ourselves

Generic arguments are 100% breaking from the v1 API

Fix some missing imports

Add`Unit.of`, `Unit.ofBaseUnits`, and `Unit.mutable` methods returning wildcarded generic types. Subclasses should override these to sharpen the signatures to the unit-specific measurement implementations like `Angle` and `Distance`.

Allows immutables to be records and easily converted to value types if valhalla ever lands

Reduces clutter in the root `units` package

Instead of separate discrete constructors for different unit types

Add code generation for the measure implementations (eg Distance, ImmutableDistance, and MutDistance) due to the sheer volume of manual work that would have been required to write (or copy/paste) ten thousand lines of code

Reconsolidate the measure implementations into a single package

Rename `negate` to `unaryMinus` and some variants of `per` to `divide` for consistent naming.  Overloads of `divide` may be renamed to `per`; TBD

Rename `Ratio` measure type back to `Per` to ease code generation. May be renamed back to `Ratio` or `Quotient`; TBD

Checkstyle and PMD are disabled for generated files

Add `per(TimeUnit)` abstract method to Unit for subclasses to implement. Often returns a velocity

Instead of relying on the default record implementation for immutable types and the autogenerated logic for mutables, check for measure equivalence

This allows for comparisons of eg `Measure<DistanceUnit>` to `ImmutableDistance` to `MutDistance` to all work correctly

For example, `convertFrom` cannot be declared in the base unit class and must therefore be declared and implemented in every subclass, and `getBaseUnit` must be overridden to return the correct type in every subclass

Make composite units consistently use the correct base units

Can't overload `times()` due to type erasure

Not as easy to combine into energy as torque, and it's a less common usecase

Rename existing function to `multAsTorque` for clarity

Add equivalent torque multiplication function to the Force class

Allows for wider compatibility with results of math operations

Allows for known `Per` object outputs instead of bounded wildcard `Measure<? extends PerUnit>`

Allows for more obvious types for readability and access to type-specific methods that would otherwise be unusable (eg `Frequency.asPeriod()`)

Some places must still be generic (eg trapezoid profile constraints and states)