fix(ext/dom_exception): align better with spec

[ghost]

Fixes #12927.
There were no issues open about the current implementation.

Uses symbolic members for DOMException, and applies branding to its getters.
Uses a null prototype for the error string->code mapping object, to avoid prototype access.
Also updates outdated specification links.

[crowlKats]

I am very unsure about this usage of __proto__, but it does seem to work. everything else looks good

[lucacasonato]

Let's not use __proto__.

The same effect can be achieved using Object.create.

[ghost]

I am very unsure about this usage of __proto__, but it does seem to work. everything else looks good

This __proto__ is a non-accessor object prototype initialization, and is the most optimised way to set it in all engines; see: tc39/ecma262#2125.

[ghost]

Let's not use __proto__.

The same effect can be achieved using Object.create.

Interestingly, this was how it was originally written, but was undone...
I'll try to leave a note about why it'll null too.

Reverted in c75f92c

[lucacasonato]

@phosra Thanks.

This is not a performance sensitive path (it runs once during build of the Deno binary). As such we much prefer things like Object.create because it more clearly communicates the intent.

__proto__ is a code smell, just like complex Array.prototype.reduce operations. These are code patterns we'd like to avoid.

[ghost]

Acknowledged, fair enough.

[crowlKats]

LGTM now

issue has been addressed