Reorganize the library for better backend flexibility.

[Drup]

The goal is more or less to solve #1, it includes #21

1. Functorize the core of the library
2. Extract the backend-agnostic part into a new library
3. Add a very WIP new library that target javascript regexs.

We should also be able to easily write an re2 or a pcre backend.

Unfortunately, since it uses functors, it means that it's not possible to write code that will easily work on any backend just with that. I tried the polymorphism approach, and it really doesn't work so well, we would need tons of parameters (or a module parameter, which sounds really terrible).

cc @rgrinberg @paurkedal for feedback ?

[rgrinberg]

I wonder if variants are the right approach here. The motivation here is to make things to work in JS right? In which case, I don't assume 2 instances of this library will be useful in the same executable.

[Drup]

@rgrinberg Unfortunately, the APIs are not exactly the same (Re can do more things). We could provide a minimal common version and use variants for that part.

[paurkedal]

If we want to avoid variants, maybe define signature for the last common denominator, and provide a module alias for each platform mapping to the most efficient implementation of that signature for the platform?