[generator] Fix invalid parsing of complex generic types.

[jpobst]

Fixes: #728

In order to prevent namespace clashes we always write non-intrinsic types prefixed with global::.

For example:

System.Collections.Generic.List<Java.Lang.Object>

becomes

global::System.Collections.Generic.List<global::Java.Lang.Object>

To do this, we have to parse a type into its component types so we can add global:: to each part. However our parsing algorithm struggles with generic types with multiple type arguments.

Thus:

System.Collections.Generic.IDictionary<System.Collections.Generic.IList<string>, Kotlin.Pair>

becomes

global::System.Collections.Generic.IDictionary<global::System.Collections.Generic.IList<string>>

and

System.Collections.Generic.IDictionary<System.Collections.Generic.IList<string>, System.Collections.Generic.IList<Kotlin.Pair>>

throws an ArgumentOutOfRangeException.

This PR introduces a new recursive parser that better understands generic types and generates the expected outputs.

[jonpryor]

These are all "positive" tests.

You should also test "negative" tests, "invalid" types. What happens if it attempts to parse System.Collections.Generic.List<> (missing type) or System.Collections.Generic.List<<> (too many <s) or System.Collections.Generic.List<>> (too many >s)?

Presumably it fails; does it? Does it fail in the way we expect? (Or does it instead return an empty string?)

[jonpryor]

Should also try nested generic types, a'la

List<List<string>.Enumerator[]>.

[jonpryor]

Should also check arrays-of-arrays, e.g. int[][][].

[jonpryor]

Also try intermixing arrays & generics, e.g. System.Collections.Generic.List<System.Collections.Generic.List<string>[]>[].

[jpobst]

Thanks for the additional test cases, they revealed a few more issues. Granted, they didn't work previously so it wouldn't have been a regression, but now we handle those cases as well!

The behavior with invalid types is "undefined". It may return an invalid type string or it may throw an ArgumentOutOfRangeException depending on how it errors. It's not really possible to reject invalid input unless we write a validating type parser that fully implements the type spec.

Luckily at this point we are simply outputting types that have already been validated by other aspects of generator so we shouldn't be seeing invalid types.