Implement the simplified pattern selection algorithm in the spec (#898)

[catamorphism]

Implement Mark Davis's suggested pattern selection algorithm in the spec. Update the "resolved values" example to use the match() and compare() methods instead of selectKeys().
Rewrite the numeric and :string selector specs accordingly.

[macchiati]

I gave this preliminary review, and it's looking good.

[macchiati]

Some small changes can support BEST, which can significantly improve performance.

[macchiati]

I would recommend adding the BEST value. It can be much more efficient, because it can return a result immediately in many cases.

The modification here is

Suggested change

	1. If SelectorsCompare(res, keys, bestVariantKeys) is `BETTER`:
	1. If SelectorsCompare(res, keys, bestVariantKeys) is `BEST`, select the pattern of `var` and return
	2. If SelectorsCompare(res, keys, bestVariantKeys) is `BETTER`:

[catamorphism]

@eemeli's preference back in October was to not include the optimization in the spec (see #898 (comment) ), to keep it as simple as possible. I think I have the same preference.

[eemeli]

Yeah, this is an optimization that we should leave out of the spec.

[macchiati]

I would like to discuss this further.

My main concern is that if we specify that a MF can only interpret the selection function return values of {WORSE, SAME, BETTER}, then it makes it difficult to upgrade MF and functions in the future if we do add a BEST.

And BEST can give an improvement, since you don't need to scan any further vars once you hit a BEST (for a 1 key v. message), or BEST,BEST for a 2-key, etc.)

If you take Arabic plurals, for example, the very common cases of 0 and 1 are BEST, and can return immediately when hit.

0
1
zero
one
two
few
many
*

Or with string match, same thing. With the following list, a match for blueberry can stop immediately

apple
banana
blueberry
...
zitherfruit

[eemeli]

Eh, as a committee I think we've determined that performance is not important for selection. I mean, if we did care about it, we'd be considering the variant order to be a validation issue and using first-match selection, which would automatically terminate on the first match and skip the compare stage altogether.

[aphillips]

I wouldn't characterize it was "not caring about performance". I would instead say that we prioritized producing the best matching outcome for a given set of keys and given a diversity of potential matching strategies by selectors.

I observe that this editorial effort is not addressing any of our group's pressing needs for v48. I agree that simplifying the example is probably worthwhile, but we are not required to optimize the example and we might go so far as to adopt a deoptimized example algorithm if such an example illustrated matching performance more clearly. Perhaps a discussion of performance and the potential for BEST would make a good article for our beautiful website?

[macchiati]

The difference here is that if the result is BEST, we increment bestCount (initially 0). In the final return, if bestCount == number_of_keys, then we return BEST.

[eemeli]

I think this is getting pretty close to being ready.

[eemeli]

I think these are the last changes?