Make FuzzyMatcher more convenient to use

[Soreepeong]

Removed the requirements to accommodate ref struct from the invoker code. Can be used as an extension method, with the shortest form of haystack.FuzzyMatchesParts(needle).

[nebel]

If we're removing methods which return an int (allowing a sort by score) then the internal logic can be greatly simplified. For example FindReverse is not needed at all, since its purpose is to optimise for score but we already know it matches after FindForward returns a valid match position. At which point you can probably remove most of the logic within FindForward as well since scoring then doesn't matter, and CalculateRawScore etc are also unnecessary.

[Soreepeong]

I actually considered removing the scoring logic, but it's still a pretty quick operation and I thought some future features may involve sorting by score. I think leaving it in would be fine; they'll just have to use the longer variant:

haystack.FuzzyMatches("needle", Mode.FuzzyParts, CultureInfo.InvariantCulture, out var score)

[nebel]

Oh, my mistake, we do still keep score as an out variable, but it's unused in Dalamud code.

[Soreepeong]

Additional thoughts: if we're to implement features to add localized names for plugins, CJK in particular can use extra fuzzy matching which would justify the use of precalculated data for fuzzy matching, such as precalculating which qwerty key sequence is equivalent to producing IME-processed characters. But I don't see that happening anytime soon, so that can be considered way later.

[MidoriKami]

I think score is useful, I personally struggle to use it though because it doesn't really have any definition or description.
I don't really want to have to change a number, rebuild, relaunch, reinject, test, just to see if the number I picked did anything.

I think it might be more useful if it was either defined what the values mean, or if it was converted into a float to represent %match or something along those lines.