Mixed domain test suite should test using the legacy domain.xml files

The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave.

This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join.

This is basically what users will do – take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311.

So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release.

We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found.

That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details.