[jsinterop] enforce additional restrictions on @staticInterop classes

[sigmundch]

We'd like to enforce some limitations to ensure the design of staticInterop classes matches static views (the future language feature that will be used to implement JSInterop in the future.) and supports the needs of JSinterop overall.

Some checks may include:

• Type parameters are not allowed in extensions or extension methods themselves
• Disallow generative constructors
• Potentially disallow . delimiters in renaming for non-top level members if such a restriction does not exist already

[srujzs]

@jodinathan

Since js_bindings is one of the biggest users of this feature, do you see any of the above being major issues?

[jodinathan]

no @srujzs.

It seems I will only have to adjust to use external factory.

[srujzs]

Great, thanks!

[srujzs]

@sigmundch Should we language version these checks? It might help avoid breaking users' code.

Also, I believe you've added this check:

Potentially disallow . delimiters in renaming for non-top level members if such a restriction does not exist already

but only for static members possibly? Do we see us needing to do this for instance/extension members as well?

[srujzs]

We no longer are requiring a single extension per @staticInterop class, so that error is removed. The other two have landed now that js_bindings is migrated.

[sigmundch]

Per the last comment, I think we can close this issue as complete. That said, we are in the process of making the type-parameter check more lax, and allow certain generic patterns.