[BDGR-180] Consider replacing vMix in-process mocks with mock server

[markspolakovs]

Some of Desktop's vMix tests use MOCK_VMIX which uses strong-mock to mock the vMix client. This isn't great for a few reasons:

1. The user experience from Playwright tests isn't great, as you need to app.evaluate (and we need to copy the TypeScript definitions on both sides to get the experience nice)
2. The mocks are brittle as they're tied to the exact sequence of vMix client operations the code-under-test performs
3. It means that the vMix client needs to be tested separately (though those tests wouldn't go anywhere as they're specific and useful)
4. We've been moving towards having less and less test-only code in the main bundle, first with MockOBSWebSocket, then with MicroServer in BGDR-161

---

The potential complication with these is that the vMix API is very different to Server's and OBS's. Rather than having a number of small functions that return chunks of the state, it primarily returns the state of the entire vMix application as one XML document using the XML function, or a slice of it using XMLTEXT, and then manipulates it using FUNCTION. This would mean that, in order to properly mock its behaviour, we would need to reply with XML documents that match (as far as possible) those returned by vMix.

Arguably we should move towards using XMLTEXT rather than than XML where possible, which would make testing this easier (and reduce the amount of data transferred on the wire). But this makes typesafe vMix operations more difficult, may not always be possible, and the data transfer is less of an issue since (currently) it's always on localhost. See BDGR-181.

_{From SyncLinear.com | BDGR-180}

[markspolakovs]

One idea I've had is to design the API slightly differently that MockOBS's. Rather than specifying the full returned state in the mock handler, we provide an initial state (likely as JSON, which then gets serialised to XML) which MockVMixAPI stores internally and always returns on a call to XML/XMLTEXT. The user then defines handlers for FUNCTIONs which can manipulate that state.

[markspolakovs]

Was done in #645 but reverted in #709.

It's busted and needs more work, in particular around XML parsing as the validation is too trigger-happy. Some work on the #385 branch.