[Enhancement] Keep the arity of generic types in their name construction

[Fread75]

Current behavior : if the name for a type is something like:
the.namespace.of.my.object.ObjectName'2[[System.Canon, mscorelib], [System.Canon, mscorelib]]

ClrMd will immediately correct it into :
the.namespace.of.my.object.ObjectName<T, T>

=> Arity has been dropped
=> Brackets changed to chevron
=> System.Canon changed to T

My suggestion is that arity should be kept :

• For some generic types, it could be the only indication that this is indeed a generic types, it is not uncommon to retrieve at first a name like the.namespace.of.my.object.Foo'1 without the generic parameter types part. (it seems to happen when the generic type is Object), it would be the only way to differentiate a generic Foo<T> and a not generic Foo.
• It would be more consistent with names retrieved from reflection
• full methods signatures contain the arity of their type, keeping the arity of the type would help to parse the signature.

Ideally, the name should contain only the arity, and nothing about the generic types. And a property "ParameterTypes" should he added to get that information (see #68 ).

[Fread75]

Hello,

I am currently using ClrMd for a professional project, and my company doesn't allow us yet to contribute to open source projects (mostly for legal reasons). They are working on it and in a few months, I would be authorized to submit a pull request to your repo.

In the mean time, I am working on a local clone of your repository. And I create here all the tickets that correspond to the commit I have made on my local repo, mostly to have your feedback in those points, and also in case that you want to correct them directly.

Regards,
Fred

[leculver]

Sorry, I think I'm going to reject this one. I don't plan to keep the arity of generic types in the name.

In the future (1.2) I plan to try to tackle generics in a better way...but due to the underlying API surface area of ClrMD (the dac) it's very, very difficult to handle generics correctly in all cases, so we will have to see what can be done then.