Redesign the optional pixmap deletion protocol to make the consumer responsible for deleting the pixmaps.

The previous optional protocol had the consumer send a message back to the producer when a pixmap was ready to be deleted, and then the producer would take it from its pool of pixmaps marked for deletion and delete it there. That protocol did not really work out in practise though, because of a race condition where the consumer would never become aware of a new pixmap (because the new pixmap value was read synchronously instead of delivered asynchronously) and then that pixmap would just sit there in the consumer's memory and never be deleted. The new optional protocol makes the consumer responsible for freeing the pixmap once the producer has marked it ready for deletion. That way the consumer can keep on using the pixmap until it needs to delete it. This is important on drivers that use loose binding, because the texture contents are undefined as soon as the pixmap is freed on the server side.

In order to represent that, there were a few new objects added. The first is a "communicator" object which handles all of the requests that come from the decorator through ClientMessage events and dispatch to the right place. The next are the individual message handlers, which determine whether or not the pixmap can be deleted immediately or if it should go into the pixmap release pool. The final is the release pool, which stores in-use pixmaps in a list which can then be marked for deletion when the texture they are bound to goes away.

Unit and Integration tests were added to demonstrate the code and protocol behaviour.

(LP: #1119608). Fixes: https://bugs.launchpad.net/bugs/1119608.

Approved by Brandon Schaefer, PS Jenkins bot.