Split up SnapshotWorker

This worker was responsible for too much work. To help it match how our
services are layed out, improve the possibility for parallelization, and
potentially reduce the amount of work that needs to be re-done in the
event of an error somewhere in the work, I am splitting up
SnapshotWorker into SnapshotterWorker and SnapshotComparerWorker.

I decided to continue with the after_commit trigger for spawning the
SnapshotComparerWorker so that the SnapshotterWorker doesn't need any
knowledge of any other workers. Since we will never have anything to
compare when the Snapshot is first created, I stuck with on update only.

This change highlights the difference between how we are handling these
two different types of work: SnapshotterWorker delegates all of the work
to the service object, which has to know how to update the snapshot
instance instance, whereas SnapshotComparerWorker is responsible for
updating the instance. I believe that this happened because we were
considering trying out different diff tools (see #8), so we architected
the SnapshotComparer in a way that was more modular; however, we had not
considered trying out different snapshotting tools, so we did not
architect the Snapshotter in a similarly modular way. I think I prefer
the architecture of SnapshotComparerWorker because of its flexibility,
so I will probably update Snapshotter and SnapshotterWorker to be
in a similar style.

Change-Id: I3abe5adc4f6de9811388e3b0e50524db22499aad
Break up Snapshot#accept!

It felt a little weird to have two method calls in a row that both end
up saving the instance. To resolve this, I split up Snapshot#accept!
into Snapshot#accept, which simply modifies the properties, and
Snapshot#accept!, which calls #accept followed by #save!.

I had considered doing this with a conditional in the worker, but this
seemed more readable to me.

Change-Id: I604bc0c95e92eec2dc2236c38491b76bf8162852