pcre: describe PREG_UNMATCHED_AS_NULL for trailing groups

[lacatoire]

PREG_UNMATCHED_AS_NULL is described as:

If this flag is passed, unmatched subpatterns are reported as null; otherwise they are reported as an empty string.

That is incomplete for preg_match(): without the flag, an unmatched subpattern is only reported as an empty string when a later subpattern matched. Trailing unmatched subpatterns are dropped from $matches entirely.

preg_match('/(a)(b)?(c)?/', 'a', $m);                            // array(2): 0, 1
preg_match('/(a)(b)?(c)?/', 'a', $m, PREG_UNMATCHED_AS_NULL);    // array(4): 2 and 3 are null

Measured behaviour of the second call:

Version	Result
7.2.34, 7.3.33	[0 => "a", 1 => "a"]
7.4.33 to 8.5.8	[0 => "a", 1 => "a", 2 => null, 3 => null]

Hence the 7.4.0 changelog entry, which follows UPGRADING for PHP 7.4:

When PREG_UNMATCHED_AS_NULL mode is used, trailing unmatched capturing groups will now also be set to null (or [null, -1] if offset capture is enabled). This means that the size of the $matches will always be the same.

The [null, -1] form is confirmed too: on 7.4.33 and 8.5.8, PREG_UNMATCHED_AS_NULL|PREG_OFFSET_CAPTURE yields 2 => [null, -1], while 7.3.33 omits the entry.

preg_match_all() is deliberately left untouched: it never had this behaviour. In PREG_PATTERN_ORDER the array is indexed by group, so trailing groups are always present — as empty strings without the flag and as null with it, on 7.2.34 as on 8.5.8. Nothing changed there in 7.4.

Fixes: #3483