being able to register wrappers from win32u makes things simpler because we then don't need a manual function in winevulkan to register the objects, and the winevulkan thunks can call directly into win32u functions.
So you plan to manage some of rbtree handling in winevulkan while others in win32u? That doesn't sound like a clean separation if the only benefit is avoiding a few manual thunks in winevulkan. It seems cleaner to have all of that on one side (probably winevulkan, but win32u is also a possibility).
win32u doesn't need client handles for anything else, unless I'm missing something. It means that if we'd keep that in winevulkan, the only thing from `vulkan_object` struct that's needed by win32u would be a handle and a parent. The handle requires an unpleasant union and the parent needs casting to be useful. That makes me question if `vulkan_object` is really all that useful... Having a dedicated per-type structs would avoid both of those. You needs it for both the device and instance, why not have two or so more?