Race in output-management heads/modes

When plugging out an output, this sequence of events can happen (and happens in practice, see https://github.com/emersion/kanshi/issues/55):

1. Compositor sends zwlr_output_head_v1.finished and destroys the object immediately. Compositor also sends a zwlr_output_manager_v1.done event with a fresh serial to apply the changes.
2. Client hasn't received the events yet. It creates a new zwlr_output_configuration_v1 with an (outdated) serial. It issues a zwlr_output_configuration_v1.enable_head request with the object that has just been destroyed by the compositor.
3. Compositor receives the request and libwayland disconnects the client with wl_display@1: error 1: invalid arguments for zwlr_output_configuration_v1@5.enable_head.

This is a race in the protocol itself. The only thing I can think of to fix it is to stop destroying immediately the zwlr_output_head_v1 objects. Instead, let the client issue a destroy request.