venus: remove shmem allocation hijack from proxy

The way blob resrouce gets created/mapped/attached breaks an assumption: successful guest mapping implies a roundtrip.

At guest kernel, we have below cmd sequence from virtio_gpu_resource_create_blob_ioctl:

1. cmd_resource_create_blob: proxy_context::get_blob + virgl_resource_create_from_fd
2. cmd_resource_map_blob: if mappable, hypervisor sets up guest mapping with fd from (1)
3. cmd_ctx_attach_resource: proxy_context::attach_resource

The mapping gets returned at (2) and guest side valid mapping ensures (2) has finished. However, we now rely on (3) to eventually attach the resource to the render worker process.

Without hijacking shm, render_context_export_blob does below, which is actually the same with hijacking the shm + a tour to the server:

1. virgl_renderer_resource_create_blob
2. virgl_renderer_resource_export_blob
3. virgl_renderer_resource_unref <- this detaches the virgl_resource from the render worker context and frees itself because the resource was expected to be attached later by virgl_renderer_attach_resource -> proxy_context::attach_resource request.

mesa/mesa!14658 (merged) exposes the issue for shmem.

This MR does below to naturally fix the above issue with or without guest kernel cmd ordering fix:

• small bug fix
  • server sets map_info fallback at blob export
• preparations for doing resource attach at blob export time
  • ensure virgl_renderer_resource_create/import_blob to error out on seeing duplicate res_id
  • start passing real res_id to blob creation, so that we can attach the correct res_id
  • proxy tracks resources created from blob export to avoid attaching them again later
• real thing
  • attach at blob export time
  • removes shmem hijack
• other refactorings
  • server removes redundant render_context_resource tracking
  • render protocol renamings and docs

/cc @olv @ryanneph