Job now means a collection of identical tasks

- configstore.JobConfig: refactor
- agent.ContainerConfig: validate in one place only
- agent.Grace: use JSONDuration, e.g. "5s", "1m", instead of integer
Remove the job scheduler component

To prevent a persisted, scheduled taskSpec from becoming an infinite
orphan if/when its agent goes away, we change the API to write
JobConfigs directly into the registry, and defer placement (actual
invocation of the scheduling algorithm) to the transformer.

This change has the effect of making JobConfigs the *true* atom of the
scheduler. We no longer have a way of richly interacting with tasks. The
main consequence there is our (eventual) migrate verb becomes coarser.
We can't really do per-task scale up, check, scale down operations
anymore. It remains to be seen if that's a problem.

The other way to solve the original issue would be to have some kind of
checking logic that said if a task was scheduled on a non-existent
agent, to mutate the task in the registry, or delete it and re-add it,
or something. But that adds another channel of information-flow, from
transformer back through the registry, which I view at the moment as
less clean and less desirable.

If it turns out that we need finely-grained migration control, that's
probably the best bet.
Reduce stuttering in ContainerInstance definition

ContainerInstance.{Config,Status} may be referred to by their direct
type names.
scheduler: prep for synthesized time
agent: de-magic-number-ify grace period limits
Merge pull request #38 from soundcloud/jobs-and-tasks

Jobs and tasks