Possible performance hit in UnitsNet.NumberExtensions and anywhere where boxing could happen

[ikijano]

There is possible performance hit if application uses heavily NumberExtensions to construct quantities, current implementation causes unnecessary GC pressure by allocation memory and slows down application. I understand the fact that using generics makes easy to implement conversion and probably reduces size of library but with tradeoff higher memory and CPU consumption at runtime.

        [Benchmark] public Length NumberToLength_Meters() => 5.0.Meters();
        [Benchmark] public Length NumberToLength_Meters_Convert() => 5.0.Meters_Convert();
        [Benchmark] public Length NumberToLength_Meters_Direct() => 5.0.Meters_Direct();

where first one is using current implementation and two variants

public static Length Meters<T>(this T value) => Length.FromMeters(Convert.ToDouble(value));
public static Length Meters(this double value) => Length.FromMeters(Convert.ToDouble(value));
public static Length Meters(this double value) => Length.FromMeters(value);

Please consider this specially in core part of UnitNet to avoid unnecessary value type boxing.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/boxing-and-unboxing

code example in sharplab.io

BenchmarkDotNet=v0.13.1, OS=Windows 10.0.18363.1256 (1909/November2019Update/19H2)
Intel Core i7-8665U CPU 1.90GHz (Coffee Lake), 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.200-preview.22055.15
[Host] : .NET 5.0.14 (5.0.1422.5710), X64 RyuJIT
Job-JVVMWO : .NET 5.0.14 (5.0.1422.5710), X64 RyuJIT

IterationTime=1.0000 s

Method	Mean	Error	StdDev	Median	Gen 0	Allocated
NumberToLength_Meters	26.59 ns	0.303 ns	0.253 ns	26.51 ns	0.0057	24 B
NumberToLength_Meters_Convert	19.74 ns	0.393 ns	0.600 ns	19.37 ns	-	-
NumberToLength_Meters_Direct	18.79 ns	0.247 ns	0.219 ns	18.72 ns	-	-

[angularsen]

Hi and thank you for the performance report. Would you be interested in attempting to improve this?