CustomElementsRegistry.define should guard against recursion

[dominiccooney]

I’m implementing define in Blink.

Brief background: Step 3 checks that a given name is not already in use in a registry; steps 8, 10, 12, 14 and 16 (maybe others) may run script; and step 19 establishes a definition in a registry.

Here's some feedback: The order of steps 3, 8/10/12/14/16 and 19 permit redefinition of a custom element name in a given registry. This is implementable but pretty undesirable from my point of view.

For example, create a constructor whose prototype property is backed by a getter which at step 10 in turn calls define with an unrelated definition of the same name. This will pass the check in step 2 (because the first invocation did not reach step 19 yet) and add one definition to the registry which is overwritten after the call returns and the original invocation reaches step 19.

It would be simpler if define did not permit recursion, or at step 3 it erected some kind of tombstone with name that prevented any recursive redefinition of name, or moved step 3 to occur immediately before step 19 so no author script could intercede between checking whether a name is in use and putting the name in use.

[annevk]

Should probably also copy @rniwa on these issues (@rniwa, you might want to click on the label to see more).