The slicing is really only changed once per Count, so move the
IsLeft-dependent logic into `Slicer` method and eliminate the `GetSpan` delegate.

Changed to also pass the already-computed `set` of unique substrings to the `CreateAnalysisResults` method, so we don't recompute the slices twice. In order than either the set or the original `uniqueStrings` can be passed, swapped that argument for the `Analyze` method to take the `uniqueStrings` as a `string[]` (which it already is at all call-sites).

Subtle bug in that the entire string is being placed in the set, not the span.

Since we are working with the same set of input strings in each strategy there's no reason to take the length every time we make an attempt (per count, both left and right justified).
Hoist the calculation of the acceptable number of collisions out to the top, do it once, and pass that number into the `HasSufficientUniquenessFactor` method for it to (locally) use up.

Benchmarks ever so slightly better.

Looks like the overhead of IEnumerable<string> is not worth the savings for the benchmark test data. Perhaps it would matter less if we were freezing more strings, but not likely

This will cost one extra `HashSet<string>` and one extra `SubstringComparer` to be allocated, but might make the code run faster.

Use the GSW strategy for virtual flattening

Replace ISubstringComparer with ISubstringEqualityComparer as that's more indicative of the interface it's exposing, and rename everything derived from that.
Fixed the implementation of FullStringEqualityComparer to not actually use the slice ReadOnlySpan(s) in the Equals and GetHashCode specializations.
Added comments for the SubstringEquality classes
Renamed the files for the specialization of the comparers.
Fixed the unit tests under debug builds.
Extended the test suite data for the KeyAnalyzer tests to exercise using the data in FrozenFromKnownValuesTests.