Review comments
Merge pull request #37 from soundcloud/jmy-heartbeat-initial-refactor

Broke heartbeat code into multiple chunks.
scheduler, agent: major refactor

- State machine in scheduler now respects the fact that mutations may
  occur in the agents from other, outside forces.

- agent.Client as a HTTP front to a remote agent.

- Helpers and miscellaneous improvements.
Merge branch 'master' into scheduler-refactor-redux

Conflicts:
	harpoon-agent/container.go
	harpoon-agent/lib/agent.go
	harpoon-agent/lib/client.go
	harpoon-agent/lib/mock.go
	harpoon-scheduler/agent.go
	harpoon-scheduler/agent_test.go
	harpoon-scheduler/registry.go
	harpoon-scheduler/state_machine.go
Merge pull request #35 from soundcloud/scheduler-refactor-redux

Scheduler refactor
scheduler: -listen instead of -http.address
scheduler: state machine implements actualBroadcaster
scheduler: mark TODO about out-of-sync handling
agent client manually manages connection
scheduler: utilize new connection-abandoning agent.Client behavior
scheduler: fix data races and small rename
-registry.filename -> -persist
scheduler: refactor how registry stores state

Formerly, the same job (i.e. the same set of containers and container
IDs) could be scheduled N times in a single scheduling domain, because
we used the agent endpoint as the key in the desired maps.

Now, we use the container ID as the key, so it can only exist once. Once
it's been placed on an agent, it'll stay there.
scheduler: try to improve unschedule behavior
scheduler: minor logging
Server subsystem [WIP]
Server subsystem [WIP]
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.