This PR replaces the regex backend with an in-house glob parser.

The parser is two-pass:

1. Tokenize the pattern string in text, escape character and other control characters that are part of the glob syntax.
2. Rework the raw tokens above as a list of text and glob tokens. These two kinds of tokens are the only ones useful to match a file path.

Pattern then walks through a given file path and returns the result.

By avoiding regex we mainly avoid to fall victim of unescaped characters that may compromise globbing. We probably also increase performance, but I haven't run any benchmark and it'd be likely a negligible advantage, since file paths are short strings.

Extensive testing is very welcome. Ideally, we should fuzzy testing this too.

Limitations

• Contrary to the globbing of common knowledge, this implementation does not support character groups ([abcd]). It only supports * and ?.
• It currently doesn't support consecutive globs. Text and glob tokens must always come one after the other. Now two * wouldn't be useful, but two consecutive ? may be. Should such need arise, I'll work on supporting it.
• It has the concept of chars, not UTF-8 graphemes. Non-ASCII characters in paths are uncommon, but I could use a crate for walking graphemes if needed.