💥Remove decimal support

[Muximize]

Changes

• Remove QuantityValue, replaced with double
• Remove TValueType from interfaces
  • Remove IQuantity<TUnitType, out TValueType>
  • Remove IValueQuantity<out TValueType>
  • Change IQuantity<TSelf, TUnitType, out TValueType> to IQuantity<TSelf, TUnitType>
  • Change IArithmeticQuantity<TSelf, TUnitType, TValueType> to IArithmeticQuantity<TSelf, TUnitType>

Changes to UnitsNet.Serialiation.JsonNet

• Deserializing previously serialized JSON for decimal quantities Information, BitRate and Power still work, but it now reads just double Value property and ignores string ValueString and string ValueType properties. This may lose precision compared to preserving the full decimal value, but decimal is no longer supported in v6.

Background

In #1195 @angularsen says:

If we change all 3 quantities to double, we have the potential to clean up a LOT of QuantityValue complexity.

This made me wonder how deep that complexity goes so I decided to experiment, and this is the result.

I must say some of these changes make me a bit sad. A lot of work and some very clever thinking went into supporting multiple numerical types, and I want to acknowledge that. 🙇

Also, I took it as far as possible but that might not be the best outcome, for example we might want to keep deserialization support. This just demonstrates a possible direction we could go in.

[angularsen]

I synced this with release/v6 branch after merging #1195 #1353

Will do a review of this next.

[Muximize]

I rebased this to clean up the commit history, which should aid in reviewing.

[angularsen]

Looks good to me!

As you said, it's a bit sad to see a lot of thought and work being thrown out, but I still do think reducing this complexity is worth it until we find a better way to support multiple numeric types in a more holistic way.

I made a few minor improvements and pushed it.

[angularsen]

I was contemplating whether we should keep the JSON serialization stuff for backwards compatibility, but I realized the JSON already was backwards compatible by storing both double and decimal (string) values. So by now only reading the double value, it should still work as before except for the change in precision that would happen even if we kept reading the decimal string value and converted that to double.