Test Coverage: Generic type generation

[dunhor]

Generic types are generated on-demand. I.e. for scenarios where the type is visible to/usable by JS. We already cover a fair amount of this with the Collections tests, but we should be more explicit about testing specific scenarios. In particular, here are scenarios where we should generate generic specializations:

• For static/non-static property types
• For static/non-static function output arguments and return values (inputs unnecessary since they are passed by JS)
  • NOTE: We should still be able to convert arrays to vector for input args
• For delegate input/output args and return values (inputs necessary since they can be implemented in JS)
• For struct members (i.e. IReference)
• For interface requires
  • Recursively, even if one of the interfaces in the chain is not projected
• For class "inheritance" (also recursively)

[dunhor]

While debugging a different issue, I thought of a somewhat interesting scenario. Consider a type Foo which requires a generic interface - say IVector<Foo>. We should validate that scenarios like this don't lead us down an infinite recursive path (idk if it will, but I can't convince myself immediately that we handle it gracefully)