String array + Comparer

[JKamsker]

Fixes https://github.com/diegofrata/Generator.Equals/issues/60

Builds on https://github.com/diegofrata/Generator.Equals/pull/62 , so you may want to merge this first

[diegofrata]

@JKamsker now that first PR is merged, you might want to rebase this one.

[JKamsker]

Oh yea... its alot... but it should really be as small as this https://github.com/JKamsker/Generator.Equals/pull/2

Ill do it asap and let you know :)

You can aswell create a preview version in the meantime of the already merged code in case i am not fast enough 😅

[JKamsker]

I think its ready @diegofrata

[diegofrata]

Finally had time to look into it and while I can see the usefulness, I must say I disagree with the approach here.

I believe the user should be able to guess how a type comparison will be done without having to refer to docs -- StringEquality alone does not tell me in which way the comparison works in a collection. Differently from the implicit mode which uses the built-in comparer for each type, I don't think we can pick unordered or ordered as the "correct" default as we don't know what the most common use case is.

I also think combining attributes, while smart, can be problematic. For example, should StringEquality work with UnorderedEquality in a Dictionary? What about SetEquality. Without analyzers, there is no indication to the user to what works together what does not. Particularly if not all cases will be supported out of the box. It also makes the implementation more complicated than needed be.

I think the way forward here is a little less sexy than composing attributes. I see two ways to move this forward:

1. Have specialised string attributes: OrderedStringEquality, UnorderedStringEquality and SetStringEquality. These should be easy for users to find discover when interacting with package in the IDE. OR
2. The existing equality attributes to carry an optional parameter for StringComparison, that only gets taken into account if generic type argument of the IEnumerable is a string or if the type of the dictionary key is a string.

I am not sure which I prefer. I am leaning towards 1 as it is the most explicit option and also easier to implement.

What do you think?