Allow driving LWR via message queue.

New abstraction for creating client managers (build_client_manager function) - if this is passed a URL - it will be treated as an AMQP URL and clients will stage by sending a single message via a queue using that connection. By default it will assume communication with a remote manager named '_default_' (the out of the box one for the LWR) - different LWR managers can be targetted by adding 'manager' as an argument to the client manager. The upshot of this is only one LWR (or one LWR with any given manager name) should target a given AMQP endpoint right now.

On the backend, message_queue_url should be defined in main section of the server.ini properties and all manaagers will bind to this URL. Again, it will be nice to allow more customization and allowing different managers to bind to different URLs, etc....

Couple more notes, right now all file actions must be executable by the LWR (instead of on client side) so "none" or "remote_copy" are the only valid file actions if the message queue variant is going to work and a shared file system is needed between Galaxy data and remote LWR server. The staging directory does not need to be shared however, so this should real immediate utility in some environments (if the LWR server can mount the Galaxy data and then a staging/scratch area used by the compute cluster the solution should be workable - and it should be much easier technically and politically to just mount Galaxy's data on one LWR server then a whole compute cluster).

Added a full integration test of this form of LWR as well as smaller test of AMQP abstraction shared between client and server for consuming and publishing messages.