Attempt to add interface for constuctors to add static properites

[Spice-King]

OK, this PR is a headache and a trip down the rabbit hole for me. It's technically a broken PR as I know one test fails, but I can't fix it without input on how.

Long story short, I'm working with a team to develop a types package for a framework (I guess that's the best way to put it, Foundry VTT for the interested), and in there they patch in a number of static and instance methods to built in objects (not ideal, but we have don't have control on this).

This was fine for most things to add static methods to things like Array and Number which had ArrayConstructor and NumberConstructor as ways to extend the constructor's types. Totally fine, up to this point. Then they added a static method for URL and URLConstructor does not exist. My temp fix locally was to manually redefine the URL variable instance since it's a type rather than an interface and slap a @ts-expect-error comment on it for now, but I figured this is something that could be fixed up stream and give everything I can a constructor interface.

Good news, I did that, works just fine for almost everything. Bad news, broke a single test because of a snowflake. So much for a simple PR to make things better. My simple patch does generate for URL (and others) the same style of constructor interface for type merging, worked for all but AudioWorkletProcessor, as it already has AudioWorkletProcessorConstructor defined.

unittests/files/audioworklet/usage.ts:3:17 - error TS2510: Base constructors must all have the same return type.

3   class extends AudioWorkletProcessor {
                  ~~~~~~~~~~~~~~~~~~~~~


Found 1 error in unittests/files/audioworklet/usage.ts:3

Now the "offending" bit is defined here

TypeScript-DOM-lib-generator/inputfiles/overridingTypes.jsonc

Lines 406 to 410 in 804bc3b

	"AudioWorkletProcessorConstructor": {
	"overrideSignatures": [
	"new (options: any): AudioWorkletProcessorImpl"
	]
	}

. This starts to open a larger can of worms than I can reasonably try to keep a lid on. Reading this at least fills me in on why AudioWorkletProcessorImpl exists to deal with the process method.

I leave this here in a vague hope that my last 4 hours of head scratching, poking, and prodding to find out why URLConstructor did not exist while trying to add it in helps somewhat.

[ghost]

All CLA requirements met.

[github-actions]

Thanks for the PR!

This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged.