Type specific equal constraints

[manfred-brands]

Fixes #4874
Fixes #4875
Fixes #4877
Fixes #2492

This is a merge of #4847, #4848, #4853 with one additional commit restricting combining Using with other modifiers.

Once Using is selected, a user supplied comparer will be called which does not have access to any Within or IgnoreCase modifiers.

The classes are now such that once a constraint specific modifiers is selected, the return type will not have the Using modifiers.
The reverse also holds, once the Using modifiers is used, the return type has no other modifiers.

[stevenaw]

Thanks @manfred-brands
I won't be able to review tonight, but your notes about Using prompted my memory back to #2492.

I'm not suggesting we account for that here already, but it did occur to me that the type-specialized equalconstraints added here could also make future features of that nature easier too.

[manfred-brands]

your notes about Using prompted my memory back to #2492.

It sometimes seems you know all outstanding issues, or have a good search method.

I'm not suggesting we account for that here already, but it did occur to me that the type-specialized equalconstraints added here could also make future features of that nature easier too.

I added a commit to fix #2492

I also worked on adding an overload to specify StringComparison but that became to big and not sure if it adds anything.

[stevenaw]

Thanks @manfred-brands !
It was not my intention to add to the scope here by mentioning that ticket, but your adding the fix is a great example of how these can improve usability along with type-safety.

I hope to have time to review within a few days

[OsirisTerje]

Awesome work! But it is quite a lot. I'll pull it down and try it out on some projects, that is probably the easiest way to check it out.

[OsirisTerje]

Checked #4874 , #4875, and #4877 : All works :-)

[OsirisTerje]

Anything else you want to do here, @manfred-brands ? Or can we merge?

[manfred-brands]

Anything else you want to do here, @manfred-brands ? Or can we merge?

Are you happy to merge to main or do we create a vNext?

[OsirisTerje]

lgtm

@manfred-brands Can we merge this in now?

[manfred-brands]

@OsirisTerje I have no access to a PC this week to resolve any possible conflicts. Feel free to merge otherwise I'll do it next week.

[stevenaw]

@manfred-brands I see no merge conflicts here at the moment. I'm happy to merge this in now for you so that it can land before other PRs, eliminating the chance of future merge conflicts.

Thanks again for your contribution here to make these APIs faster and more usable.