Eliminate pugi or any xml dependency

[rpatters1]

Given the stated desire in the README to eliminate dependencies, something we might consider is replacing pugi with an interface class that defines all the requirements for an xml parser in MX. Then the client could create an implementation with whatever parser they wish.

For example

const auto writeResult = documentManager.writeToStream(documentId, output);

might become

const auto writeResult = documentManager.writeToStream<MyMxXmlImplementation>(documentId, output);

I used this approach in musxdom, and it has been great. I was able to use MuseScore's own xml parser rather than introduce pugi when I and another guy created the direct finale importer for MuseScore. (Sadly, so far, not merged.) Personally, I think MX would be a great choice if they ever decide to rewrite their musicxml import-export. (Sorely needed, imho.) Having this would be one less friction point. (It is true that I converted them from tinyxml2 over to pugi about a year ago, but the point is we could go through their xml frontend rather than assume a backend.)

musxdom provides (in addition to the xml parser interface class) optional implementations for pugi, tinyxml2, rapidxml, and QtXml. If MX were to go this route, you'd need at least one of them to run the tests. (Probably pugi.)

I would also recommend this approach for zip functions (if we ever do mxl) and json (if it were ever required).

[webern]

The funny thing is, I had an abstraction over Pugi called ezxml prior to the very recent regen of mx::core to support 4.0. It used interfaces (as opposed to the template version you show above... does that use C++20 concepts?). I didn't provide a way to inject a custom wrapper over the interfaces though and it seemed unneeded so I dropped it.

Anyway, yes this would not be difficult to do. It could, possibly offer an option to omit the vendored pugixml implementation for those who will be injecting their own XML Dom parser.

[webern]

It could be done better, but it was like this:

https://github.com/webern/mx/blob/0e222f2fdda41b66cac702852aee88fb07fb3990/src/private/mx/ezxml/src/include/ezxml/XElement.h#L35..L44

  public:
    virtual ~XElement() = default;
    virtual XElementPtr clone() const = 0;

    virtual XElementType getType() const = 0;
    virtual bool getIsNull() const = 0;

    virtual bool getIsProcessingInstruction() const = 0;

    virtual std::string getName() const = 0;
// ...

[rpatters1]

It was not a C++20 concept, though that seems like it might be the right fit now that we are on C++20. It's possible I did not need the template at all in retrospect, but then I would have had to supply the parser as an argument to the factory function. Here is my interface: https://github.com/rpatters1/musxdom/blob/main/src/musx/xml/XmlInterface.h

The way I am imagining it, the vendored pugi would become a dependency of the tests. The MX library itself would have no xml dependency at all, and clients could use whichever xml package they preferred.

Musxdom provides this implementation for pugi: https://github.com/rpatters1/musxdom/blob/main/src/musx/xml/PugiXmlImpl.h. MX would need the equivalent of this for its tests, and ideally it would be available for a client to use by supplying their own pugi.

(There are some macros in musxdom that do some of this automatically, but I am increasingly convinced they were a bad idea.)