Added strict types for WebGL and WebGL2

[NaridaL]

I wrote some strict types for WebGL/WebGL2, if you want to add them to the core, it would fix #5855 among others.

The auto-generated typings would need to be excluded. Maybe this should be added as a separate option for the lib compiler option as it's not exactly lightweight.

I might have made some of the types too strict, for example for texImage2D I added overloads which exactly match the internalFormat/format/type combinations allowed by the WebGL spec. When calling the function with immediate values, this is fine, but calling it with values in variables is going to require as any casts. (Which could be fine, as at that point you're responsible for the correct types anyway).

Also the following would fail, because TS doesn't currently generate a common supertype (?).

declare const randomParameter: GL['ACTIVE_TEXTURE'] | GL['ALIASED_LINE_WIDTH_RANGE']
const x = gl.getParameter(randomParameter)
// no matching overload, but a return type of GL.TextureUnits | Float32Array would make sense.

I'd appreciate some feedback as to whether types likes this would be merged (they're NOT backwards-compatible for one) and if so, what changes would be necessary, before I put more effort into tests/correct generation of libs.

[NaridaL]

Without Strict, obviously, this is currently to avoid name conflicts with the existing declarations.

[NaridaL]

Nullable and sequence should probably be inlined.

[mhegazy]

We keep DOM related definitions in https://github.com/Microsoft/TSJS-lib-generator

You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TSJS-lib-generator.

For future references, please file an issue first to track changes.

[NaridaL]

@mhegazy Yes, but considering the size of these types and the fact that there is very little overlap with the auto-generated version, specifying them as differences in inputfiles/addedTypes.json doesn't seem feasible.

The issue I linked above tracks what this solves as far as I can tell, and is marked as help wanted. Is this not the type of solution you were envisaging for that issue?

[mhegazy]

Is this not the type of solution you were envisaging for that issue?

We really keep all the DOM lib definition and generation in one place. the reason is newer versions of the idl files have some of these types, and we get to remove some of the hand-authored ones as time goes on.