wet_process: Fully split wet_process and wl_client

This MR does a bunch of stuff, but the overriding theme is to properly encapsulate and split process handling.

wet_process is a renamed weston_process (as it lives in the frontend) which only tracks a process and nothing else. It's more cleanly carved out into a separation of a thing that tracks processes and a thing that tracks clients. Doing so involved a bunch of changes to the Xwayland launching API. Now it only ever sees clients, and the process tracking is contained entirely within the frontend. This was pretty easy and mostly just involved deleting code, but the intermediate commits have a bunch of code motion.

At the end of this series - which also cleans up a couple of other users - we flip on ASan leak checking, and it works for all the non-DRM tests without reporting leaks. I ran it a few hundred times to be sure, and the only failures I saw were a rogue Xwayland assertion from cleanup_after_cairo() where we find some Cairo objects still active. This already happens in main and looks like some kind of irritating race around cleanup. I'm not yet sure what's happening here but I do know that it's not caused by this series at least.

Open questions (cc @pq):

1. Not a question per se, but the DRM tests need to be fixed as they leak stuff both in the backend and the test code
2. Also not a question but the Xwl API version needs bumping
3. Should custom_env live in wet_ frontend namespace, or should it be a new welp_ helper library to live alongside libweston? It needs to be exposed somehow as it's part of wet_ API
4. Same question for fdstr, with the third option of 'should it just stay internal'?
5. I'm like 99% sure that wet_client_launch should be renamed to wet_process_launch and I'm kicking myself that I only realised this now, but whatever
6. Should wet_client_start also take custom_env and the array-of-FDs thing? (I think yes because why not? The split right now is incredibly arbitrary)
7. Should wet_process_destroy also have an option for whether or not to terminate the process? I think it makes sense for it to be selectable: one path for 'I don't care what happens to this client, just forget it' like wet_client_start, and another path for 'please kill this process and stop tracking it' like shutdown probably wants
8. Maybe other stuff, I don't know.