Typemap cleanup

[deadlocklogic]

This PR cleans TypeMap into a modular design.

[tritao]

Thinking we should rename this into CSharpTypeMappedIndex as well to keep the same convention.

[deadlocklogic]

Yes indeed, I will review all the changes carefully a final time.
I was a bit analyzing the C# backend and after a lot of digging I found out that CLI backend uses C# backend typemaps too. So we need to load all available typemaps, and let the user select them according to their GeneratorKind.

[deadlocklogic]

Thinking we should rename this into CSharpTypeMappedIndex as well to keep the same convention.

After my next commit, we can actually define each TypeMap in its own namespace and therefore avoid name collision.

[deadlocklogic]

By the way, in a separate PR I want to introduce 3 concepts which leverage TypeMap concept even more.
1- Registerable typemaps: therefore we can register typemaps manually with custom predicate, not strictly bound by the type as string anymore <= something which will give huge advantage over SWIG.
2- Ability to register many typemaps which might collide, we just return the latest registered one.
3- This one is a bigger one: introduce DeclarationDatabase concept which will allow attaching typemaps and other heuristics to a declaration, and which will have priority over global heuristics.

[deadlocklogic]

@tritao Basically the PR is ready for a review. I will do another checkup and see if everything is OK so you can merge it.
As you can see now, the typemaps are fully independent/self contained => easily extendable for new generators:

namespace CLI
{
    [TypeMap("TestMappedTypeNonConstRefParam", GeneratorKindID = GeneratorKind.CLI_ID)]
    public class TestMappedTypeNonConstRefParamTypeMap : TypeMap
    {
        public override Type SignatureType(TypePrinterContext ctx)
        {
            // return Stub
        }

        public override void MarshalToManaged(MarshalContext ctx)
        {
            // Stub
        }

        public override void MarshalToNative(MarshalContext ctx)
        {
            // Stub
        }
    }
}

namespace Cpp
{
    [TypeMap("TestMappedTypeNonConstRefParam", GeneratorKindID = GeneratorKind.CPlusPlus_ID)]
    public class TestMappedTypeNonConstRefParamTypeMap : TypeMap
    {
        public override Type SignatureType(TypePrinterContext ctx)
        {
            // return Stub
        }
    }
}

[deadlocklogic]

The only problem with this PR will be backward compatibility, but this is the only way going forward. We can rename MarshalToManaged to MarshalToScript or something similar but this is not of high priority.

[deadlocklogic]

Here we explicitly specify GeneratorKind.CSharp because CSharpTypePrinter is used in CLI. Many similar cases are found in this file, src/Generator/Passes/ExpressionHelper.cs and src/Generator/Passes/ValidateOperatorsPass.cs

[tritao]

Not sure I totally understand why, why is it a problem to pass GeneratorKind.CLI in these cases?

[deadlocklogic]

After a bit of analysis and tests I found out that the CLI backend depends on CSharp typemaps in some ways.
Consider the DelegatesPass which is common for CLI and CSharp, it uses CSharpTypePrinter which itself uses the CSharp typemaps. Not passing the GeneratorKind.CSharp explicitly will make the DelegatesPass uses CLI typemaps, which is not desirable in this case.
Consider the Employee.h example:
Using CLI typemap (undesired):

// Employee.h CLI generated header
[::System::Runtime::InteropServices::UnmanagedFunctionPointer(::System::Runtime::InteropServices::CallingConvention::Cdecl)]
delegate ::System::String^ Func__System_String^ ___IntPtr(::System::IntPtr __instance);

Using C# typemaps (desired):

// Employee.h CLI generated header
[::System::Runtime::InteropServices::UnmanagedFunctionPointer(::System::Runtime::InteropServices::CallingConvention::Cdecl)]
delegate ::System::String^ Func_std_basic_string___Internalc__N_std_S_basic_string__C___N_std_S_char_traits__C___N_std_S_allocator__C___IntPtr(::System::IntPtr __instance);

Apparently this signature must match the CSharp one (in the generated .cs file) in order for the project to compile.
To he honest, I was a bit confused why such mess is going on, but then I focused on refactoring rather than changing semantics.
This is why I am working on refactoring the project into modular design because with its current status it is nearly impossible to afford more generators with new semantics/heuristics. Isolating generators is a big win for future development, allowing reusable components as the current status which is also good (but we should add remarks/best practices).
Maybe someone with deeper knowledge on how the CSharp/CLI backend is operating can help us too. I can invest some time into these backends and see how they can be improved (and you should know that there is a lot of room for improvements), but I am thinking of sparing my efforts for newer generators.
By the way, I was thinking if we can standardize/document the typemap concept in details because it is a major concept in binding generation and currently I am finding it a bit confusing when comparing its usage across different generators. Maybe a kind of README/pseudocode can help a lot for users/collaborators.

[tritao]

Can we remove this if now?

[deadlocklogic]

To be honest, I am not totally sure, I can try removing it and run the tests and see what goes on. Here I am refactoring while keeping the same semantics.
We can investigate desired behavior thought, I don't exactly know if this behavior is intended exclusively for CLI/CSharp or can be extended for other generators.
Isolating the current tightly coupled architecture needs many steps, which this PR addresses one of them.

[deadlocklogic]

My next PR, when this passes, will introduce the concept of Registerable typemaps.
Consider:

[TypeMap("basic_string<char, char_traits<char>, allocator<char>>", GeneratorKindID = GeneratorKind.CLI_ID)]
public class String : TypeMap
{
}

This is messy for sure, hardcoded types are risky, let alone the verbosity and tight rules.
This can be refactored into a more elegant solution, while still taking benefit of the reflection system.

public class String : TypeMap
{
    // Can be null for global typemaps
    public static GeneratorKind SupportedGeneratorKind()
    {
        return GeneratorKind.CLI;
    }

    // Now we can use this predicate for any type: No more checking for template specialization name: like in std::map
    public override bool IsTypeMatch(Type type) // or MatchesType not really sure about the naming convention
    {
        return /* Stub */ true;
    }
}

After this we don't necessarily need TypeMapAttribute, and TypeMapDatabase will have cleaner interface, while delegating the typemap matching to the typemap itself. So a cleanup would eliminate the ID concept introduced in an earlier PR.
Another note, in its current form the TypeMapDatabase is running multiple stages for typemap querying (checking against TemplateSpecializationType etc ...), when in fact these steps should be carried out by the typemap itself in a fine grained way. We can add helper methods for desugared matchers in the TypeMap class for easier usage.
Suppose we want to add a custom typemap which only works for types which inherit from BaseClass.
In the current form, this is close to impossible.
Marshalling pointers to opaque types will be nothing more than a simple typemap.
This issue #1788 might benefit from this too, next to DeclMap too.

[deadlocklogic]

Another notice: few changes are just formatter changes induced by visual studio formatter. Maybe adding a format file would unify codestyle across different IDE's. (I can revert such changes if you want).