Supporting explicit quantity types in the Quantity types

[seanpearsonuk]

This follows some discussion with @h-krishnan. At the moment, Quantity is in terms of units without the context of specific quantity types. But if the intended quantity type is known, that would lead to a more appropriate choice of units for a given Quantity objects.

Consider some use cases

force_times_displacement = Quantity("5.0 [N]") * Quantity("12.0 [m]") # 60.0 [Nm]
work = Quantity(force_times_displacement, type="work done")  # 60.0 [J]
# "work done" chosen as the quantity because it has fewer terms:
more_work = work + force_times_displacement # 120.0 [J] 

temp_diff = Quantity("50.0 [C]", type="temperature difference")
# temperatures:
temp1 = Quantity("30.0 [C]")
temp2 = Quantity("20.0 [C]")
# implicitly a temperature difference because of the `-`:
temp_diff = temp2 - temp1
# implicitly a temperature: 
temp2 = temp2 + temp_diff 
# implicitly a temperature difference: 
temp_diff2 = 2.0 * temp_diff 

[h-krishnan]

Essentially, we should keep track of and propagate the unit quantity rather than the dimension of the values.

Unit Quantity: Pressure, Velocity, Force, Torque, Work etc.
Dimension: Length, Mass, Time etc.
Unit: Pa, m, kg, hour etc.

We can associate a Unit Quantity Map ( { Unit Quantity : power }) with every real value solver setting or expression/report definition value. (e.g. boundary_conditions.inlet['inlet1'].vmag ==> {Velocity : 1}, Volume Integral of Pressure at fluid ==> { Pressure: 1, Volume: 1}.

We can also associate a unit to a Unit Quantity. (e.g. Pa implies Pressure, N imples Force). So, Quantity(1, "Pa") is associated with { Pressure : 1}, whereas Quantity(1, "N m") is associated with { Force : 1, Length : 1}.

We can have rules for simplification of Quantity maps. e.g. { Force : 1, Length : 1} can be simplified to { Work : 1}.

Mathematical operations will automatically propagate the unit quantity map. For addition/subtraction etc, the term with the simpler unit quantity map will win.