ParameterState: Add optional IEqualityComparer

[ScarletKuro]

Description

Fixes when custom comparison is required.

Replaced non generic ParameterState with a builder.

Builder pattern is really good when overloads grow exponentially, so I had to drop the non generic ParameterState helper for the builder pattern. While it's still manageable for RegisterParameters it wasn't the case for the ParameterState helper.
It's much easier to use now ParameterAttachBuilder, it has own drawbacks like you need to set the T explicitly, it can't get it from the context, BUT ParameterAttachBuilder should not be used by anyone, not by users and not by contributors, it's exclusively for the tests and the RegisterParameters to build complex ParameterState<T> which has so much optional arguments and in future it may only grow.

How Has This Been Tested?

None as for now, unit tests are work in progress

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[ScarletKuro]

@henon missing unit + bunit tests, which i will add later, but the feature itself is ready to be reviewed.

[codecov]

Codecov Report

Attention: Patch coverage is 67.24138% with 38 lines in your changes are missing coverage. Please review.

Project coverage is 88.75%. Comparing base (a047ed3) to head (75b793c).
Report is 5 commits behind head on dev.

Files	Patch %	Lines
...dBlazor/Base/MudComponentBase.RegisterParameter.cs	55.29%	38 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #8416      +/-   ##
==========================================
- Coverage   88.88%   88.75%   -0.14%     
==========================================
  Files         414      416       +2     
  Lines       12294    12372      +78     
  Branches     2455     2459       +4     
==========================================
+ Hits        10928    10981      +53     
- Misses        836      860      +24     
- Partials      530      531       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[henon]

The builder makes a lot of sense. I didn't know it at the time but the gut decision for the RegisterParameter method in the component constructor was the right one, seeing that it is now able to abstract a lot of complexity away from the framework user.

After reading our CONTRIBUTING.md, people still seem to be managing to shoot themselves in the foot with the framework. I will think a bit on how to improve the docs without making them overly long and exhausting to read.

[ScarletKuro]

In this PR I also moved the NumericConverter.AreEqual logic to the separate DoubleEpsilonEqualityComparer, because:

• It how it should be from the beginning
• I used the DoubleEpsilonEqualityComparer for the SetParametersAsync_CustomComparer_HandlerShouldFire and SetParametersAsync_CustomComparer_HandlerShouldNotFire tests.

I also added tests for DoubleEpsilonEqualityComparer, since this logic is a copy-paste from the java implementation of https://floating-point-gui.de/errors/comparison/ therefore I also copied the tests from https://floating-point-gui.de/errors/NearlyEqualsTest.java but not all of them, because we use different MinNormal compared to the JAVA version, and the tests are specifically optimized for the FloatMinNormal = (1 << 23) * float.Epsilon, we would need to use the same one to have 1:1.

[ScarletKuro]

Added bUnit test. Merging as the feature is complete and fully tested.

[ScarletKuro]

@henon now when I look at some components I think I made a mistake and the IEqualityComparer should be a Func because some components have IEqualityComparer defined as [Parameter] and it's used dynamically for specific parameter.
For examle in tree the

[Parameter]
[Category(CategoryTypes.TreeView.Selecting)]
public IEqualityComparer<T?> Comparer { get; set; } = EqualityComparer<T?>.Default;

And it's used for the SelectedValue and this is a problem since Comparer can change at any time, while currently we set in ctor.
We could just create SetComparer in IParameterState, but then you'd have to change it yourself everytime, therefore it would be nice if it would be automatic via Func.

[henon]

... therefore it would be nice if it would be automatic via Func.

Agreed