Iterating over the NamedNodeMap returned by Element.prototype.attributes is unsafe and vulnerable to race conditions

[botandrose]

Closes #41 . More context there, but the gist of it is resolving this issue:

From https://www.oreilly.com/library/view/javascript-the-definitive/0596000480/re534.html (emphasis mine)

Although the NamedNodeMap interface allows you to iterate through its nodes by position, it does not represent an ordered collection of nodes. Any changes made to the NamedNodeMap (such as by removeNamedItem( ) or setNamedItem( )) may result in a complete reordering of the elements. Thus, you must not modify a NamedNodeMap while you are iterating through its elements.

[botandrose]

More here. Benchmarking reveals roughly 5% perf hit due to all the array instantiations: https://www.measurethat.net/Benchmarks/ListResults/33103 , and we still haven't verified if this is the issue or even the fix! Not great.

I did find a unmerged PR for morphdom that seems to address the exact same issue, but in a simpler way. This may be performant enough to do instead, and also describes the exact circumstances needed to reproduce. https://github.com/patrick-steele-idem/morphdom/pull/242/files

So I'm going to move forward with:

1. Trying to create a failing test using attributeChangedCallback to remove a second attribute when a first is removed
2. Verify the fix
3. Benchmark this other strategy

[botandrose]

@1cg Okay, this is ready for your review.

Benchmarks here: https://www.measurethat.net/Benchmarks/ListResults/33105

It seems about the same in Chrome, slightly slower in Safari, and slightly faster (?!) in Firefox.

Semi-interesting footnote: Array.from(el.attributes) also makes the test pass.