quantities of any numeric type

[erikerlandson]

Related to #2, but would apply to Quantity, making its internal value type non-opaque.

The tricky part of this is rules for interaction between values of differing types, and output types as function of input types. Also touches on internal representation of conversion factors, and understanding if and when to preserve "integer-ness"

[erikerlandson]

Straw-man concept

1. Declared unit coefficients stored/represented as spire Rational type. This will enable exact representations of the larger unit prefixes, and various rational coefficients, such as 5/9 for C/F conversion factors, and prevent floating-point representation losses, etc. Since these operate at compile-time, the additional expense is very low impact.
2. Quantity parameterized by additional numeric representation type R
3. numeric operations (+, *, etc) are permitted only for quantities having the same R
4. operators '*', '+', 'pow', will no longer map units canonically. They will simply preserve the "named" units in their operand UnitExpr expressions. In other words, a "trust the user" policy. If a resulting unit type expression is weird or inefficient, there is no loss, since it can always be converted later if that is necessary. This also eliminates the cost of applying conversion coefficients.
5. In cases where conversion coefficients are in play, detect when the factor is 1 and eliminate it. To do this at compile time will probably require factoring out the macros into separate sbt subproject
6. General policy of converting coefficients to the quantity representation type. For the case of integer representation types and non-integer coefficients, do multiplications in non-integer space and then round. Use Rational?
7. Casting of representation types is a separate operation from converting unit expression types.
8. Conversion does not change representation type

[erikerlandson]

This is essentially resolved by PR #11, currently merged to the release_0.2.0 branch