Major refactoring: refactor GeneratorKind enum into a class

[deadlocklogic]

This PR is the first step towards a modular Generator creation/registration.
The current model doesn't allow the user to create a custom generator unless he modifies the sources and accommodates for the custom generator changes, which is a disadvantage for users who like to use nuget and prefer modular designs.
This PR just transforms the GeneratorKind enum into a class, and makes the needed changes.
If approved the next step, would be widening this concept, and let the GeneratorKind take care of the generator model:
1- providing the type of the generator and instantiating it
2- providing the type of generator options
3- resolving the name of the GeneratorKind
etc...

This is one of first steps which will make the integration of this library easier and more natural.

[deadlocklogic]

@tritao if you want I can continue refactoring next steps and see the final work.

[deadlocklogic]

@tritao, now you can easily see my point in action:
You can now freely create your own generator/tool in a modular fashion without the need to modify/recompile the sources.

class Program
{
    class TestLibrary : ILibrary
    {
        public void SetupPasses(Driver driver)
        {
        }

        public void Preprocess(Driver driver, ASTContext ctx)
        {
        }

        public void Postprocess(Driver driver, ASTContext ctx)
        {
        }

        public void Setup(Driver driver)
        {
            {
                DriverOptions options = driver.Options;
                options.DryRun = true;
                options.GeneratorKind = MyGeneratorKind;
                options.OutputDir = @"...";

                var module1 = options.AddModule("Test");
                module1.IncludeDirs.Add(@"...");
                module1.Headers.Add("...");
            }
        }
    }

    class MyGenerator : Generator
    {
        public MyGenerator(BindingContext context) : base(context)
        {
        }

        public override List<CodeGenerator> Generate(IEnumerable<TranslationUnit> units)
        {
            throw new NotImplementedException();
        }

        public override bool SetupPasses()
        {
            throw new NotImplementedException();
        }

        protected override string TypePrinterDelegate(AST.Type type)
        {
            throw new NotImplementedException();
        }
    }

    static GeneratorKind MyGeneratorKind = new GeneratorKind("MyGenerator", typeof(MyGenerator));

    static void Main(string[] args)
    {
        ConsoleDriver.Run(new TestLibrary());
    }
}

[deadlocklogic]

The next step will be adding a property for CLI flags in the GeneratorKind and refactor hard coded switch cases for CLI flags.

[tritao]

Nice, I am looking the direction this is going, I will provide a more detailed review ASAP.

[deadlocklogic]

Nice, I am looking the direction this is going, I will provide a more detailed review ASAP.

No problem, I am working on the things we discussed too! Great progress so far.
If you need to have a better support for other scripting languages (maybe let users work their own generators/tools in separate repositories) you should consider avoiding the whole project being tightly coupled with C# generator.
I understand that the project started as an exclusive C# generator but things should change going forward.
Solving binding generation for any language should take a universal approach IMO.
I will work towards bringing and improving bindings generation of dynamic scripting languages in a methodical way.
My only demand is to have a stable C++ Parser module because currently there might be problems parsing some libraries and the whole process aborts if compilation fails.

[deadlocklogic]

Ok I will stop pushing on this PR, until I get some feedback.
Notice now, any custom generator you create and register (by creating its GenerationKind variable) is automatically resolved in the command line as long as you provide a CLIOptions property. (I could've checked if the provided CLIOptions conflict with already registered kinds but lets keep it simple for now, although the mechanism is already in place).
I will work on refactoring the remaining switch cases into option properties in GenerationKind for full portability/extendibility.

[deadlocklogic]

@tritao Let me know when you are ready, I have another PR which:
1- add TypePrinter Type as a property to GeneratorKind.
2- implement a TypePrinter for each generator separately (even it inherits from another one, because some generators don't have one).
3- rename each generator's namespace correctly (currently it is a total mess, for instance every NAPI component is under namespace CppSharp.Generators.Cpp)

I am almost done working on another PR which cleans up TypeMap so each GeneratorKind can have its own TypeMap without the need to refactor other typemaps or add more virtual methods, so different typemaps don't necessarily interfere.

[tritao]

@tritao Let me know when you are ready, I have another PR which: 1- add TypePrinter Type as a property to GeneratorKind. 2- implement a TypePrinter for each generator separately (even it inherits from another one, because some generators don't have one). 3- rename each generator's namespace correctly (currently it is a total mess, for instance every NAPI component is under namespace CppSharp.Generators.Cpp)

I am almost done working on another PR which cleans up TypeMap so each GeneratorKind can have its own TypeMap without the need to refactor other typemaps or add more virtual methods, so different typemaps don't necessarily interfere.

Looks good, looking forward to the following PRs.

[deadlocklogic]

@tritao Things will look great I am pretty confident about it. The codebase I've been working on is stable and extensively tested.
Its API is about 95% matching CppSharp's.
My whole philosophy which I am working hard to achieve is: write a config script => get bindings for many languages with minimum hassle.
SWIG is good at bindings but pretty much helpless on the C++ AST level for the user, so for instance considering the Lua language, SWIG is a poor choice because it requires too many boilerplate from your side which itself requires knowledge of the codebase you are binding. It wont generate overrides for smart pointers/inheritance interop etc...
Being able to generate bindings with full control over the AST is far more superior and generates accurate bindings with less efforts, with lot of customization points available for the user: TypeMap, Options etc...
My whole point of refactoring the Generator into a modular design is: you can now even write custom generators for SWIG itself which generate the needed boilerplate code, without even modifying CppSharp sources!
My ultimate vision which I am working towards:
1- create a git repo
2- add the library you need to bind as submodule
3- imports CppSharp nuget package
4- write a C# config file (maybe even in IronPython!!!) for generation
5- create a github-action which generates the bindings
We can even create a template for this whole process and automate bindings.
I believe then the demand on this library will increase drastically.
The only thing which is important in this project is to maintain a stable CppParser module.