ResolvePluralRange does not account for approximately formatted ranges

[eemeli]

Specifically, this happens:

const nf = new Intl.NumberFormat("en-US");
nf.formatRange(1, 1); // "~1"

const pr = new Intl.PluralRules("en-US");
pr.selectRange(1, 1); // "other"

A more reasonable English plural category for "~1" would be one.

Effectively, I think we need something like this bit that's in PartitionNumberRangePattern for ResolvePluralRange as well, so that when the corresponding NumberFormat output would be a single number, its category is determined solely from that number, rather than from the start/end pair:

6. Let xResult be ? PartitionNumberPattern(numberFormat, x).
7. Let yResult be ? PartitionNumberPattern(numberFormat, y).
8. If xResult is equal to yResult, return FormatApproximately(numberFormat, xResult).

Partly this may be a product of implementations relying on CLDR data, which is more strict than this proposal about its applicable range:

The data has been gathered presuming that in any usage, the start value is strictly less than the end value, and that no values are negative. Results for any cases that do not meet these criteria are undefined.

[sffc]

Hmm. CLDR doesn't really have data for the approximately sign. As an English speaker I don't know if "~1 apple" or "~1 apples" sounds more correct; I read it in my head as "about one apple" or "about one apples".

@macchiati @pedberg-icu @zbraniecki Thoughts on this?

[sffc]

I think we can move forward with @eemeli's proposal above, giving implementations the flexibility to do as they please with approximately plurals. Probably add a new AO PluralRuleSelectApproximately.