This will be useful if not necessary at some point for shared resources, to send / receive fds with the D3DKMT requests.
There's maybe an option to use `wine_server_fd_to_handle` / `wine_server_handle_to_fd` instead, but that would require creating file objects for every resource on the server side, and that seemed a bit unnecessary.
Also, on the macOS side, we will likely want to extend these helper and the fd_type enum, to include and support sending / receiving mach_port_t fd types, as shared resources are backed by those on that platform. This probably doesn't fit too well with the otherwise unix file fds and the fd cache.
It's maybe a bit awkward to squeeze the fd type bits into the request header but I didn't find a good other way and increasing its size breaks the size <= 64 assumption. It could be a pointer within the request struct passed to the helper call, but it seem a bit awkward from a usage point of view: hard to make it clear that it needs to be within the request struct.