WIP Moving back towards using named runs.

* Rename artifactsRepo -> buildDataDir to be more explicit about the fact that
  it holds more than just the artifacts.
* Revert removal of run ids.
* Move Worker definition into core as part of making the core responsible for
  accepting run requests.
* Make the core module more responsible for internal details of data structure
  and storage. External callers should not need to construct paths to
  artifacts, versions, etc. but should be able to call method in the core
  module to do this work for them.
* The working directory no longer contains anything but the checked-out code.
  All StrawBoss-specific data is stored by StrawBoss elsewhere.
* Add a regular maintenance cycle to the server module.

README.md

@@ -53,8 +53,9 @@ the `strawboss` executable. This is the configuration file for StrawBoss
 itself. The contents are expected to be a valid JSON object. The top level keys
 are:
 
-* `artifactsRepo`: A string denoting the path to the artifacts repository
-  directory.
+* `buildDataDir`: A string denoting the path to the directory where StrawBoss
+  keeps metadata about builds it has performed and the artifacts resulting from
+  the builds.
 
 * `authSecret`: Secret key used to sign JWT session tokens.
 
@@ -113,12 +114,7 @@ object. The top level keys are:
 
 * `versionCmd` *(optional)*: a command to be run in a shell (`sh`-compatible)
   that is expected to print the current version of the project on `stdout`.
-  It is important to note that if you supply a verion command it should provide
-  a unique result for every commit in the repository. StrawBoss is built around
-  the assumptions that builds are repeatable and that every buildable point has
-  a unique version id. This is the reason that StrawBoss does not create uniue
-  IDs for individual builds. The combination of project name, build step, and
-  version *is* the build ID. *(defaults to `git describe --tags --always`)*.
+  *(defaults to `git describe --tags --always`)*.
 
 ####  Step Definition