[Finder] Fix Glob::toRegex() producing an invalid regex for bracket expressions containing a slash - #67785

…s wrong (KalimeroMK)

This PR was merged into the 6.4 branch.

Discussion
----------

[Finder] Fix three bracket expressions Glob::toRegex() gets wrong

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | -
| License       | MIT

#67785 stopped `Glob::toRegex()` returning an invalid regex for a bracket expression holding a `/`.
Three shapes still get it wrong. I compared every result below against PHP's own `glob()` on a
directory holding the matching names.

**`[:alpha:]` compiles to nothing.** PCRE reads the whole class as a POSIX one and refuses it:

```php
preg_match(Glob::toRegex('[:alpha:]'), 'a');
// Warning: preg_match(): Compilation failed
// bool(false)
```

A POSIX class needs the outer brackets, so `[:alpha:]` is the set of the characters `:alpha`, and
`glob('[:alpha:]')` matches `:` and `a`. The `:` is escaped now, and `[[:alpha:]]` is untouched.

**`[[-?]` compiles to nothing.** Its range runs backwards, which POSIX leaves undefined and PCRE
rejects. `glob('[[-?]')` matches nothing, not even a file of that name, so the bracket expression
becomes `(?!)` when PCRE will not take it.

**`[[:alpha:]` matched the wrong thing.** `$scanEnd` records that no `]` closed the `[`, and the
next `[` before that point reuses the answer. That is wrong for a `[` the scan swallowed as part of
a `[:...:]`, which can still open a bracket expression of its own: `glob('[[:alpha:]')` matches
`[:` and `[a`, not the literal pattern, and `glob('[[:alpha:]/]')` matches `[a/]`. The assertion in
`testGlobToRegexBracketsAfterAnUnclosedOne` changes for that reason.

Comparing `Glob::toRegex()` with `fnmatch()` over 12906 pattern/subject pairs leaves no pattern
that fails to compile.

Commits
-------

4b6d3b0 [Finder] Fix three bracket expressions Glob::toRegex() gets wrong