Fixes a bug where new XML("<node />").childNode[0].parentNode did NOT refer to the overall document object, but to a phantom text node.
This is because the swap operation used to construct an XMLObject's node in-place was happening AFTER parsing, which means that referents already existed to the temporary XMLNode created by XMLObject::new. swap is not to be called after tree structure has been created; it does not update referents to the swapped nodes.
In the future I should examine the implications of explicitly reconstructing already existing nodes, e.g. through XML.apply(some_xml). Right now, the existing node will be swapped with a new one, and two nodes will exist pointing to the same script object, which is a huge problem with our overall design. We should, at the very least, disassociate swapped nodes from their script object, just in case they still have referents.
Ideally, we wouldn't have to swap nodes, but to avoid a swap, I'd have to instead have a second layer of indirection just to hold a rewritable pointer that every XMLObject points to. This isn't really worth it unless I HAVE to do it, so I'm not going to do it.
This test technically works, but the results were slightly surprising. If it turns out Flash works differently from `quick_xml`, we'll change this test to match Flash.
`quick_xml` was chosen due to it's high performance and support for zero-copy use cases. However, we are not using `minidom`, which is the already-extant DOM impl that uses `quick_xml` as it's parsing provider. This is because `minidom` nodes are not amenable to garbage collection.
Specifically: we want to be able to construct a new `Object` variant that holds part of an XML node. However, `minidom::Element` directly owns it's children, meaning that we can't hold references to it from within `Object` while also keeping those objects to the `'gc` lifetime. Hence, we provide a GC-exclusive DOM implementation.
I ruled out solutions such as holding an entire XML tree in an `Rc` and having AVM objects that shadow them. This works for `SwfSlice` because indexing an array is cheap; but traversing a tree can get very expensive. XML is used in many places in Flash Player, so it's important that we treat it like a first-class citizen.