Use the regex package in replacement of the built-in re module

[eldipa]

Describe the feature you'd like
The idea is to replace the standard re module with the third party regex module.

There are a few reasons to do it:

• the was not intention of releasing the GIL by re while regex can do it (and it can be enforced with concurrent=True). The lack of multithreading support by re prevented to use threads instead of multi-processes in byexample which are, obviously, more expensive.
• byexample uses heavily the regex engine but all the regex used in a single run are different, unique. This means that the traditional cache of re is pointless because it disappears after each run (byexample is restarted and as any process the OS frees its memory). That means that in each run byexample needs to re-compile every single regex which it is very expensive. Pickling is pointless because currently re pickles only the expression and it compiles it when it loads the pickle so we don't save any time. regex, however, supports pickling the bytecode directly. Note: we should test how much we win with this.
• despite of been heavily optimized, the regex created by byexample may lead to a catastrophic collapse (endless high CPU usage). re does not support atomic groups or possessive qualifiers that could reduce the impact of a catastrophic backtracking (see Use a Thompson NFA instead of the Python default re (regex) engine if it is possible #16). re neither supports timeouts. regex in the other hand supports all of them.

[eldipa]

From 81edc42 we have the following observations after instrumenting and measuring the time for building a regex object (compile function) and using that regex to match a given string, for all the examples of parse_sm.py's documentation:

• regex's compile function is 96 times slower than re's one. (order of 300 microseconds against 3 microseconds)
• regex's match function is 2.5 times slower than re's one. (order of 8 microseconds against 3 microseconds)

Despite showing the worst performance regression, compile slowness may not be so important if we can implement a regex cache; the performance of match may be is a problem.

[eldipa]

Merge branch onto master (#133 ) reverted in fc9b1c4 due the performance regression.

[eldipa]

Running a full suite of tests with the profiler on shown that _exec function using regex ran 12% slower that using the re engine.

[eldipa]

At the moment, regex will not be integrated in byexample:

• it is possible to use regex instead of re and the [PoC] Issue 128 replace regex engine #139 proved it
• the performance regression, however is of ~12%. It could be reduced further but it would require the use of a cache. This is already present in 9.2.0 but it is unclear if the complexity will pay.
• GIL is a problem in python. In Multithreading implementation as a replacement of multiprocessing #131 and Issue 131 multithreading implementation #138 (multitheading), byexample has a maximum of parallelism of 2 to 4 jobs (threads) but the use of regex didn't change the results. The regex engine has little impact on the contention of the GIL.

It could be possible (maybe) to integrate part of #139 to add a layer of abstraction and make byexample and the modules agnostic of the regex engine to be used. This will make the transition to regex easier in the future with a minimal cost.