Extend SecurityHelper to allow generation of different "kind"s of keys.
There has been talk about including the object's class into the hash when generating keys so the ids are not overlapping between model types. This change could allow that, but my immediate desire is to just to create single-purpose per job keys to allow external job running code to access files on behalf of a given job.
Implement API allowing access to a job's files.
Provides a mechanism for remote job execution mechanisms to read and write files on behalf of an "active" jobs.

For a variety of reasons simply providing access to datasets is insuccifient for this - there are working directory files needed for metadata calculation, inputs and outputs may be of intermediate form (task split files for instance), tool files, location files, etc.... Therefore this API endpoint provides access to a jobs view of these files.

Some attempt is made to verify the paths that are written to are valid for the supplied job (they either correspond to the output datasets of the job or the working directory of the job). Authorizing suchs paths for reading is much more difficult and left undone due to the unstructure and arbitrary nature of .loc files.

To implement this securely and with minimal configuration required - single-purpose "job_key"s are generated to authenticate these API calls. Each key allow usage of the API only for a single, active job.

Update LWR job runner to be able to leverage this API to stage files remotely via HTTP for "remote_transfer" actions (added recently to the LWR client).
Merged in jmchilton/galaxy-central-fork-1 (pull request #327)

Implement job files API.
PEP-8 fixes, var name fixes, and unit tests for SecurityHelper.
Tests cover nearly all functionality - in particular newly added per-kind key generation.