Consider manual parsing and handling of regex

[PgBiel]

The regex module currently just forwards all regex strings to Nix's built-in regex matching and splitting functions. However, Nix uses POSIX ERE syntax for regex, which is more limited than the syntax available in other Gleam targets. For example, \s for whitespace doesn't work, and must be replaced by [[:space:]]. Similarly, \d needs to be written as [0-9] for example.

We could solve this by manually parsing regex on compile and transforming into a format that Nix accepts. In particular, we'd look into tackling the following incompatibilities:

1. Properly handle \s and \d, which are widely used across Gleam packages;
2. Handle other Regex escapes, such as \n;
3. Handle case-insensitive flag;
4. Handle multi-line flag;
5. Handle (?!x) (negative lookahead);
6. Handle (?:x) (ignored group).

1 and 2 would require parsing and replacing depending on the context (inside/outside character classes - a simple global replacement isn't enough, since the [ ] in [0-9] have to be dropped when already inside a character class).

3 would basically consist of converting letters such as a or A into [aA], and would require parsing in the same manner.

4 could perhaps be done by splitting the string into lines first and joining matches on each line.

5 could perhaps be done by replacing (?!x) with (x)? and storing the capture group number; later on, when using match functions, matches where the group is present would be ignored (additionally, the group would be removed from submatches).

6 could be done by replacing (?:x) with (x) and then removing the group from submatches later, by storing the group's number after parsing.

Now, parsing with Nix could be inefficient, but we expect compile to be a "slower" operation anyway. This would allow proper compatibility with the ecosystem.

We could also test if parsing would be needed anyway first , otherwise just pass the regex through.