Allow fractions, complex numbers, NaN for a Quantity's number

[matterhorn103]

• NaN is already permitted as it is part of Decimal just like inf and -0, but important to check that Quantity's methods don't run into issues due to assuming that number will always be real
• Keep complex or Fraction when used to create a Quantity
• Account for different behaviour of those types in methods of Quantity (and of Unit) i.e. that not everything works with all types
• Methods that only make sense with decimal quantities should just fail with complex/Fraction and the onus is placed on the user
• Detect strings "1+2j" "1/2" as being complex and fractional respectively and pass them to complex() or Fraction() as appropriate

[matterhorn103]

Notably, rounding would require a different implementation.

When used on a Fraction, the number seems to be rounded in the normal way for floats, but expressed as a decimal fraction e.g.

• 1/4 --> 1/5 (half down to even)
• 7/20 --> 3/10 (half down, because float(0.35) = 0.349999..., so is still to even)
• 11/20 --> 3/5 (half up to even)

Meanwhile, complex doesn't even define __round__(). So would we make rounding work for complex quantities via another method, or would we let it return the same error for consistency with Python's implementation?

[matterhorn103]

Since complex is kind of annoying, can't be cast to anything else, and has different methods to Fraction and Decimal, for implementation of complex numbers it might be worth considering adding an imaginary decimal component to Quantity.

This would require reimplementation of the whole logic of complex numbers though – presumably a pointless reinvention of the wheel that is likely to lose a lot of optimization benefits of complex.