class DeleteVmo

The server should delete the passed-in `vmo` and any associated

resources before responding.

Sysmem guarantees that `vmo` is the only handle remaining to the VMO.

The call to [`fuchsia.hardware.sysmem/Heap.DeleteVmo`] should fence the

cleanup of `vmo` and any associated resources before responding. Because

the last handle to `vmo` is passed in via

[`fuchsia.hardware.sysmem/Heap.DeleteVmo`], the server can defer

completion of the [`fuchsia.hardware.sysmem/Heap.DeleteVmo`] until

ZX_VMO_ZERO_CHILDREN is (very soon) triggered on the server's parent VMO

due to the server closing the passed-in `vmo`. FIDL server bindings

support responding to a request async. There is no requirement to

process any other incoming messages on this channel until

[`fuchsia.hardware.sysmem/Heap.DeleteVmo`] is done.

The effectiveness of sysmem's

[`fuchsia.sysmem2/BufferCollection.AttachLifetimeTracking`] mechanism

relies on resource recycling being complete before the response to this

call.

[`fuchsia.sysmem2/Allocator.GetVmoInfo`] stops working after there are

zero outstanding sysmem-provided VMOs derived from this VMO, and before

this call starts. Any attempt to call

[`fuchsia.sysmem2/Allocator.GetVmoInfo`] before responding to this call

will also deadlock due to sysmem waiting on this call to complete before

processing [`fuchsia.sysmem2/Allocator.GetVmoInfo`].