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.

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?

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.

Hey @deadlocklogic, haven't heard from you in a while, hope everything is good.

Are you still interested in working on this?

Lua support would be really awesome to have and you've done quite a lot of nice work on this already!

@tritao Honestly I did quite a lot of work on Lua and other languages.
While I really liked this project in the beginning, I discovered that it has the right idea but not the optimal setup.
I believe the project should've been written in C++ based on the clang API directly.
While being written in C# with an independent AST is theoretically great, but practically slow and memory hungry for big libraries.
I have been working on an alternative solution in the past months, which is more similar to SWIG, and which at some point will be open source.
I can submit my work, which is basic and covers much of the use cases (because the other generators of this project aren't fully implemented too).
But for further development I am following my approach, which is incredibly fast compared to the current approach.