Add the possibility to instantiate a QuantityFormatter

[lipchev]

Just like the UnitParser and the QuantityParser can be created with an UnitAbbreviationsCache - the same goes for the QuantityFormatter.

This should allow for different parts of the application to use their own "defaults".

In terms of implementation - we can keep the static Format methods, but they should delegate the call to the Default instance.

There is a slight problem with the name collision- but my plan involves changing the instance member generic parameter to

    public string Format<TQuantity>(TQuantity quantity, string? format, IFormatProvider? formatProvider)
        where TQuantity : IQuantity

This avoids the boxing of the struct via the IQuantity<TUnit> interface which is currently used by the static Format.

Now, obviously once this is done- the two existing overloads should be deprecated, however the question arises- whether there should by a static alternative or can we simply point to the QuantityFormatter.Default? Note that should we decide to have the static TQuantity versions, then we won't be able to have both use the same name..

We should probably also take / expose an instance of the QuantityFormatter on the UnitsNetSetup, but that's not a requirement.

[angularsen]

Sounds good.

Regarding static methods, I don't think QuantityFormatter.Format() is something many do, it feels more of an internal component to me, so I vote for instance methods only and require users to go via UnitsNetSetup.Default.QuantityFormatter.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[lipchev]

Blocked by #1507