Make it easier to polyfill built-in extensions

[RReverser]

This PR adds separate interfaces for constructors, similarly to how lib.es*.d.ts define ECMAScript built-ins.

This ensures that downstream typings can extend built-in constructor with static methods when polyfilling new and/or unstable features.

This was not possible with inline type declarations, because TypeScript does not allow variable declaration merging, but it is possible with a separate interface because you can declare them with the same name downstream, and it will get merged into the base type.

[saschanaz]

This idea has been rejected because it would generate too many new global names and thus would cause more global pollution.

[RReverser]

@saschanaz Well it aligns better with built-in ECMAScript APIs, and not doing this is causing real problems (unability to polyfill static methods).

For example, right now I'm blocked on this (or any alternative solution) to be able to define types for js-types proposal of WebAssembly that adds static type() to a bunch of built-ins, and there's no workaround that I know of, and I'm sure this is not the only API that is running into similar issues.

[RReverser]

If the concern is specifically the global namespace, we could put all these declarations into some sort of artificial module e.g.

declare module 'dom-constructors' {
  interface AbortController { ... }
  ...
}

var AbortController: import('dom-constructors').AbortController;

[RReverser]

For the reference: #222 (comment) seems like even a better option, and would also allow extending built-ins.