No-namespace element serialized in a namespace if DOM Level 1 xmlns attribute set

(Likely related to #47 but filing separately, because this is a reverse way of looking at the same problem space.)

https://bugzilla.mozilla.org/show_bug.cgi?id=1763779 gives the following example:

let doc = document.implementation.createDocument("", "", null);
let xmlEl= doc.createElement("Plan");
xmlEl.setAttribute("version", "1.0");
xmlEl.setAttribute("xmlns", "http://www.example.com/");
doc.appendChild(xmlEl);
let outputString = new XMLSerializer().serializeToString(doc.documentElement);
console.log(outputString)

In Gecko (where the XMLSerializer API originates), this outputs: "<Plan version='1.0'/>" That is, the element isn't in a namespace in the DOM, so to keep it not in a namespace in the serialization, the xmlns attribute is dropped.

In WebKit and Blink, this outputs: "<Plan version='1.0' xmlns='http://www.example.com/'/>". That is, by retaining the xmlns attribute set via DOM Level 1, the element moves into a namespace in the serialization.

I believe the Gecko behavior is correct per the original intent of the semantics of the API, WebKit miscloned the API, and Blink inherited the WebKit bug. However, I don't know what the Web compat implications are at this point.

The spec should be clear about which behavior is intended. If there aren't pressing Web compat reasons to have the WebKit/Blink behavior, I think we should have the Gecko behavior, which is XML-wise correct.

Start with the XMLSerializer example in the issue and compare the documented Gecko, WebKit, and Blink outputs, then review related issue #47 and Bugzilla 1763779. Done means the specification clearly defines whether a DOM Level 1 xmlns attribute on a no-namespace element is retained during serialization, with web-compat implications addressed.