In MQ-mode, have LWR poll status updates less aggressively.

Do this by adding new manager option (min_polling_interval) to enforce a minimum interval between status checks. This defaults to half a second right now.
Add small note about chaussette not respecting server.ini port.
Config and run.sh bits for uWSGI.
Improved and improved use of job metadata abstraction.
python-drmaa does not like int job ids:

    File "lwr/managers/util/drmaa/__init__.py", line 51, in job_status
      return self.session.jobStatus(external_job_id)
    File ".venv/lib/python2.7/site-packages/drmaa/session.py", line 518, in jobStatus
      c(drmaa_job_ps, jobId, byref(status))
    File ".venv/lib/python2.7/site-packages/drmaa/helpers.py", line 299, in c
      return f(*(args + (error_buffer, sizeof(error_buffer))))
    ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type
Improve error handling when draining LWR queues.
Enable AMQP heartbeat to remove consumers that die unexpectedly.
Update client for recent Galaxy changes.
Update client for recent changes in Galaxy source tree.
Refactor code for creating amqp_exchanges so more can be shared between LWR backend and Galaxy.

This (plus small hack) allows more AMQP options to be specified with LWR such as amqp_consumer_timeout and amqp_publish_retry.
Add job_metrics_conf.xml to .hgignore.
Fix small logic bug in 87dfc76.
Merge in slurm CLI runner from Galaxy (implemented by Jeremy).
WIP toward CLI baed submission of asynchronous jobs.

Idea is to allow one to submit jobs to remote hosts without formal LWR server running. This changeset starts work on an LWR client variant allowing this by bringing in the Galaxy's CLI runner to remotely execute shell commands. (Alternative remote execution mechanisms such as fabric or ansible may also be awesome to add in here.)

Much work still needs to be done in terms of creating the script referenced in this changeset to spin up the LWR, stage, submit or run directly a job, unstage, and connect to a MQ to register completion.

Once that is done - an alternative method of operation to target a new Galaxy API endpoint could be cool as well (so one could do this without the message queue in place).
Better handling of new kind of CLI message client.
Separate web from core stuff in lwr/app.py.
Move all web stuffs into lwr.web. Refactor core app into lwr/core.py.

Deprecating old wsgi app_factory module in lieu of lwr.web.wsgi.
Allow choice of wsgi container in run.sh...

... in prelude to non-web modes of launching run.sh.
Experiment in getting LWR to run as a daemon instead of webserver using daemonizer.

This implementation is probably incomplete and incorrect - but prototype job worked.
Working prototype of CLI shell initiated asynchronous LWR.

Create script infrastructure for launching LWR jobs from a command-line (either using a base64 encoded json object or a simple file). Fixup client stuff to deal with this properly.