Splits `XPCServer.forThisProcess(...)` into separate functions

[jakaplan]

This conceptually partially reverts the decision to make retrieving an XPCServer (aside from anonymous ones) all happen as part of one function. Implementation wise this is quite different than before as will be described.

The three functions are:

1. forThisXPCService() - nothing too interest, basically does what it says on the tin
2. forMachService() - this function is where a lot of goodness/magic happens, it basically returns a fully configured XPCServer for a Mach service so long as it conforms to one of four the built-in types and only has one Mach service present
3. forMachService(withCriteria:) - this is a highly customizable variant of 2 which makes use of the new XPCServer.MachServiceCriteria and can support any type of Mach service.

All of this is built with the principle of progressive disclosure, so I expect most API users will never use the third function and that's fine.

One thing worth noting that I realized was wrong with the previous design is that it's perfectly valid for a helper tool to provide multiple XPC Mach services simultaneously. As such it's essential to have access to the non-blocking start() function and it's quite useful to be able to still have auto-configured client requirements while specifying just the name of the service, which can now be done with XPCServer.MachServiceCriteria.

A nice internal side effect of these changes is that XPCMachServer now does not concern itself with all of the various built-in types, that's all factored out into XPCServer.MachServiceCriteria.

[jakaplan]

@amomchilov For your review when you have time. It's a rather sizable change, although for the most part it's a refactoring.

[jakaplan]

I'm going to merge this in to continue work on some other changes, but always open to feedback at a later date