All types of ECMAScript NativeErrors are always subtype reduced between themselves

Nobody has claimed this yet.

### ⚙ Compilation target

ESNext

### ⚙ Library

es5

### Missing / Incorrect Definition

All error instance types defined in es5 are equivalent in eyes of TypeScript, but are distinguishable at runtime with `instanceof`.
Here is how each error is defined right now:
```ts
interface XError extends Error { // <- Same as Error!
}

interface XErrorConstructor extends ErrorConstructor {
new (message?: string): XError
(message?: string): XError
readonly prototype: XError
}

declare var XError: XErrorConstructor
```
As you can see, any error is structurally equivalent to another, including `Error` itself. This makes the issue propagate to error constructors as well.

On a somewhat related note, child classes of `Error` (`class MyError extends Error {}`) do not have this issue.

###### This affects libraries that attempt making error-handling typed (for example, [Effect.ts](https://effect.website/), [NeverThrow 🙅](https://www.npmjs.com/package/neverthrow), etc.), making them unreliable when using built-in errors. (Which are, arguably, the most commonly used type of errors.)

### Sample Code

```TypeScript
// Should be (SyntaxError | TypeError)[]
const twoErrors0 /*

Start with the ES5 NativeError declarations and the sample type-inference cases in the issue. Check how the current declarations make the built-in error types structurally equivalent and how subtype reduction handles their constructors. Done means the native error types remain distinguishable in the shown array and return-type examples, with regression coverage for those cases.

Written by the indexing model from the issue text.