Registrable generators: add support for lua, python

[deadlocklogic]

This PR will add support for registrable generators: lua, python etc..., basically any language which has a registration API.
This will be the migration of my own work which I talked about many times before, it should be a straightforward task, bear with me.

[deadlocklogic]

I have to refactor the last part which interferes with this PR: the passes.
Right now some passes have undesired effects, like templates, bitfields are automatically excluded from generation, which shouldn't be generalized.
FieldToPropertyPass shouldn't be forced on all generators, especially for scripting languages.

[tritao]

Haven't gone through this in detail yet, but can you explain what it means for a generator to be registrable? Why do we need this new concept?

[deadlocklogic]

I am not finished yet though, this is just is bare minimal implementation, still many concepts missing: templates, protected base classes, typemaps to name a few. So I advise you to not review the code in detail because, the common code will be extracted away.
Basically from my experience, there are 3 major techniques to bind with C++, we can call them generator families/categories:

Structural:

Just like the C# generator, it is C++-like code structure for binding.
Such family is useful too for generating API functions, just like the typescript one.
Pseudocode:

class Type {
    Type();
    void method();
}

Registrable:

Like sol, pybind, luabind, and any C++ helper library built on top of a C style API
Pseudocode:

Scope {
type<Type>(state)
.constructor<Type>()
.method("method", &method);
}

Functional:

Here bindings will heavily rely on creating a separate function for each binding entity (just like with pure C API):
Pseudocode:

void wrapper_type_constructor(state s) {
// ...
}
void wrapper_type_method(state s) {
// ...
}
// And then we register all the functions to the state.

So I thought creating a base generator for each of these 3 concepts will ease the extension for newer one.

I prefer these categories to reside in separate folders not in the current hierarchy, but for now I will keep them there to avoid messing with the build system.

Haven't gone through this in detail yet, but can you explain what it means for a generator to be registrable? Why do we need this new concept?

As far as I noticed, the only feature complete generator to some extent is the C#/CLI one (it is a general assessment), the others are just prototypes, incomplete work etc..., with a lot of redundancy between them.
What I am trying to do is introducing common concepts which will implement all the needed boilerplate in a methodical/documented way, the user's task will be easy with minimum margin of errors.