Fix customized built-in element is handling and reactions

[domenic]

This uses the new "is value" concept introduced to DOM in
whatwg/dom#262, which more correctly implements
the intention that changing the is attribute after element creation does
not impact the processing model, and thus fixes #1298. This allows us to
then fix #1360: custom element callback reactions for customized
built-in elements were not correctly looking up their definition.

Do not merge until whatwg/dom#262 is merged. @dominiccooney and an editor to review.

[dominiccooney]

LGTM

FWIW in code we have a pair of local-name, name which we call a descriptor and use as a key for matching elements to definitions. "name", if set, is always a valid custom element name, and it lets you represent all kinds of elements:

1. name is not set ⇒ not a potential custom element
2. local-name == name ⇒ autonomous
3. local-name != name ⇒ customized built-in; local-name must not be a valid custom element name

This is isomorphic to the representation you have here, but it might be useful—you no longer talk about matching the name string, which is tedious/tricky with the existence of customized build-in elements, but instead on associating this tuple with an element and then using that to match definitions (both parts must match.)

[annevk]

I like that alternate representation, but this change is okay too.