Stdlib.CSharp.cs: remove buggy typemap

[deadlocklogic]

Closes #1810

[deadlocklogic]

@tritao I can push the regenerated bindings too if you want.
Adding more tests for containers is necessary too.
I noticed that the C# backend never uses System.Collections.Generic anyway, or am I missing something?
We can add an option in the C# generator: dotnet version.
I was planning to improve options for each generator, but I am still not decided on the best option as generators are lazy initialized in the Driver. Do we need to provide a generator option with the driver or should we implement a Configure() method in the ILibrary where we can configure the generator once intialized?

[deadlocklogic]

@tritao going forward, we should be very careful about changes which might break other backends unintentionally. Like in #1783 changes were made to improve the C# backend, not taking into consideration other backends. Because CheckIgnoreMethod in src/Generator/AST/Utils.cs is a shared method across backends.
So extra measures to isolate the generators logic to the maximum should be taken, a simple/trivial backend-specific change can easily modify the behavior of other generators undesirably.

[tritao]

@tritao I can push the regenerated bindings too if you want. Adding more tests for containers is necessary too. I noticed that the C# backend never uses System.Collections.Generic anyway, or am I missing something?

Isn't it used in this type map? Can you explain the rationale for removing this type map? Won't it break std::map for C#?

We can add an option in the C# generator: dotnet version.

Why do we need the dotnet version? Isn't the issue we have right now with the C# language version, which is an independent concept?

I was planning to improve options for each generator, but I am still not decided on the best option as generators are lazy initialized in the Driver. Do we need to provide a generator option with the driver or should we implement a Configure() method in the ILibrary where we can configure the generator once intialized?

Not sure, what do you think is best?

[deadlocklogic]

Isn't it used in this type map? Can you explain the rationale for removing this type map? Won't it break std::map for C#?

This is the root of this typemap.

    [TypeMap("std::map", GeneratorKindID = GeneratorKind.CLI_ID)]
    public partial class Map : TypeMap
    {
        public override bool IsIgnored { get { return true; } }

        public override Type CLISignatureType(TypePrinterContext ctx)
        {
            var type = Type as TemplateSpecializationType;
            return new CustomType(
                $@"::System::Collections::Generic::Dictionary<{
                    type.Arguments[0].Type}, {type.Arguments[1].Type}>^");
        }

        public override void CLIMarshalToNative(MarshalContext ctx)
        {
            throw new System.NotImplementedException();
        }

        public override void CLIMarshalToManaged(MarshalContext ctx)
        {
            throw new System.NotImplementedException();
        }

        public override Type CSharpSignatureType(TypePrinterContext ctx)
        {
            if (ctx.Kind == TypePrinterContextKind.Native)
                return new CustomType("Std.Map");

            var type = Type as TemplateSpecializationType;
            return new CustomType(
                $@"System.Collections.Generic.Dictionary<{
                    type.Arguments[0].Type}, {type.Arguments[1].Type}>");
        }
    }

Let's check an std::map bound instance: in CppParser\Bindings\CSharp\x86_64-pc-win32-msvc\CppSharp.CppParser.cs:
Bound field: Decl.h: DeclarationContext=>std::map<std::string, Declaration *> anonymous;

namespace Std
{
    namespace Map
    {
        [StructLayout(LayoutKind.Sequential, Size = 16, Pack = 8)]
        public unsafe partial struct __Internalc__N_std_S_map____N_std_S_basic_string__C___N_std_S_char_traits__C___N_std_S_allocator__C____N_CppSharp_N_CppParser_N_AST_S_Declaration___N_std_S_less__S0____N_std_S_allocator____N_std_S_pair__1S0__S3_
        {
            internal global::Std.CompressedPair.__Internalc__N_std_S__Compressed_pair____N_std_S_less____N_std_S_basic_string__C___N_std_S_char_traits__C___N_std_S_allocator__C___N_std_S__Compressed_pair____N_std_S_allocator____N_std_S__Tree_node____N_std_S_pair__1S1_____N_CppSharp_N_CppParser_N_AST_S_Declaration__v___N_std_S__Tree_val____N_std_S__Tree_simple_types__S7__Vb1_Vb1 _Mypair;
        }
    }
}

internal global::Std.Map.__Internalc__N_std_S_map____N_std_S_basic_string__C___N_std_S_char_traits__C___N_std_S_allocator__C____N_CppSharp_N_CppParser_N_AST_S_Declaration___N_std_S_less__S0____N_std_S_allocator____N_std_S_pair__1S0__S3_ anonymous;

So this typemap had no effect.
Does it have effect on parameter thought, I am not 100% sure because there are no tests there? (But notice the CLI typemaps throw new System.NotImplementedException();)
If you want to be as safe as possible:

1. merge Revert "Typemap cleanup" #1810 which will revert Typemap cleanup #1802
2. write extensive tests for containers
3. I will rework the PR

Whenever I finish my milestones with higher priority, I can work exclusively on:

1. improving the tests
2. improving the CLI/C# backend overall (writing docs/pseudocode etc...)
3. upgrade typemaps functionality to match al least SWIG level

[deadlocklogic]

Why do we need the dotnet version? Isn't the issue we have right now with the C# language version, which is an independent concept?

Sorry if I mixed up the matters: I meant adding option for C# version because #1783 introduced C# 10.0 requirements.

Not sure, what do you think is best?

I will work out an elegant solution for sure.

[deadlocklogic]

@tritao I will add tests for std::map and even std::list myself and see what goes on. Lets wait and check for ourselves.

[tritao]

Ok, I think I understand now. This type map is probably some old attempt to implement map, and thus should be removed because its buggy.

[deadlocklogic]

I am adding tests anyway 😂