Remote multi-process support #354
Description
Current approach to remoting assumes a 1:1 correspondence between a client and a server. The client manages Ids and the server associates the resources to those Ids. Problem is that in Gecko we need multiple content processes to run WebGPU workloads on the same GPU process.
If we use multiple Id spaces with the wgpu server on the same process, we'll have collisions of Ids because the HUB is global.
One approach could be to split the Id space (in addition to backend/epoch/id separation) into one more dimension - by client Id.
Another approach could be making HUB explicit, such that wgpu-native never needs to access it globally. That could be done by having the "Context" as the first parameter to every exported C function, regardless of remote/local. Then wgpu-rs could technically still have HUB as a global and just pass an address to it in the first param.
At the same time, Gecko would explicitly create a context for each IPC channel it establishes, and no Id collisions would occur. I like this solution in particular because having the context explicit goes more in line with Rust idiomatic approach and gives us more control.