client: Support destroying GlobalList through wl_fixes

[Drakulix]

Mostly a perquisite for supporting wl_fixes v2, when that lands, but it doesn't hurt to expose the ability to destroy the registry. Luckily wl_fixes has no events yet, so this makes it really easy to bypass the clients State and handle it fully internally.

[ids1024]

Luckily wl_fixes has no events yet

And I guess if a future version of wl_fixes adds events (not sure if that's likely) this still won't require any immediate breaking change. (At worst we'd ignore the event, and clients needing to handle the fixes event would need to bind a separate instance of the global.)

[ids1024]

The other question here would be if we need to bind a wl_fixes instance here all the time, instead of lazily creating one when .destroy() is called. But we ultimately will want that for #887.

It could also make sense for GlobalList to have a Drop impl that destroys the registry, but that would be a breaking API change. So at least for now we should leave that out.

[ids1024]

After calling fixes.destroy_registry(), we also need to call Backend::destroy_object(). Compare https://github.com/rust-windowing/softbuffer/pull/218/changes which is probably still the only thing that's using wl_fixes in a wayland-rs client so far.

This PR also seems to be missing a call to fixes.destroy() to destroy the instance of wl_fixes itself. Probably in Drop.

[Drakulix]

I have added the backend.destroy_object() call as well as fixes.destroy(), but to the destroy-method.

The reason being, that for #887 we technically could still be using the wl_fixes-object for acknowledging global removals, even after the GlobalList has been dropped.

This can be changed as well, if we decide to free the registry on Drop.

[ids1024]

The downside of this is that if GlobalList::destroy isn't called, that wl_fixes instance is leaked. But it isn't really a big deal to leak an object without any events, compared to leaking the registry. Since we'll need wl_fixes for #887, that seems acceptable.

[ids1024]

Testing in softbuffer, this seems to behave as expected.

rust-windowing/softbuffer#350