That way we can add fancy-regex support behind a feature.

* Adds a std::error::Error impl for Error
* Adds a backtracking limit to mitigate catastrophic backtracking

Without this, some parsing benchmarks took 30% longer to run.

Some of the regexes include `$` and expect it to match end of line. In
fancy-regex, `$` means end of text by default. Adding `(?m)` activates
multi-line mode which changes `$` to match end of line.

This fixes a large number of the failed assertions with syntest.

In fancy-regex, POSIX character classes only match ASCII characters.
Sublime's syntaxes expect them to match Unicode characters as well, so
transform them to corresponding Unicode character classes.

With the regex crate and fancy-regex, `^` in multi-line mode also
matches at the end of a string like "test\n". There are some regexes in
the syntax definitions like `^\s*$`, which are intended to match a blank
line only. So change `^` to `\A` which only matches at the beginning of
text.

Note that this wasn't a problem with Oniguruma because it works on UTF-8
bytes, but fancy-regex works on characters.

Always adding `(?m)` for the entire regex meant that `.` also changed meaning,
which is not what we want. The safer option is to use `(?m:$)` for `$` only.

That also means we don't have to bother with `\A`. But we do need to parse
look-behinds because we can't use `(?m:$)` in it.

Turns out `(?m:$)` works in look-behinds, just not `(?m)$(?-m)` which I was
using before.

Includes the fix for
fancy-regex/fancy-regex#37 which caused a test
failure with the Java syntax.

Might be worth introducing a specific feature for this and then have
other features depend on it? Not sure.

This applies the regex rewriting fixes on this branch to the default
packs.