[Grapheme] Reject out-of-range offsets in the grapheme_str[ri]?pos() family

[nicolas-grekas]

Q	A
Branch?	1.x
Bug fix?	yes
New feature?	no
Deprecations?	no
Issues	-
License	MIT

ext-intl requires the offset of grapheme_strpos(), grapheme_stripos(), grapheme_strrpos() and grapheme_strripos() to be contained in the haystack, and throws a ValueError on PHP >= 8 otherwise:

grapheme_strpos('abc', 'b', 4);   // ValueError: Argument #3 ($offset) must be contained in argument #1 ($haystack)
grapheme_strpos('abc', 'b', -4);  // ValueError, same message

The polyfill clamped the offset while cutting the haystack instead, so out-of-range values silently returned either false or, for negative offsets far enough from the end, a match found in the whole haystack:

Grapheme::grapheme_strpos('abc', 'b', 4);    // false
Grapheme::grapheme_strpos('abc', 'b', -10);  // 1

The valid range is -$len to $len inclusive, $len being the length of the haystack in grapheme units. Out of it, this PR throws the same ValueError as ext-intl on PHP >= 8, and returns false on PHP 7 like ext-intl did there. In-range behaviour is untouched.

This is what made symfony/string return a position where ext-intl makes UnicodeString::indexOf() return null: symfony/symfony#64992 relies on catching that ValueError, so its new test cases fail on the x86 / minimal-exts / lowest-php job, where intl is missing.

The added test covers the four functions on both implementations. Note the calls have to be literal, since a variable function call bypasses the namespaced functions TestListenerTrait installs and would only ever exercise ext-intl.