Refactor replay

Refactor the replay package.  This change breaks the replay into well separated pipeline stages, namely:

[parse BSON] ---op---> [controlRate] ---op---> [batchOps] ---[]op---> [applyOps]

Each stage controls the lifetime of their own output channels, closing them when appropriate.  Each stage also properly exits early in the case of failure.  The design of the new package is influenced heavily by [this blog post on pipelines](http://blog.golang.org/pipelines)
This update also makes oplog-replay compatible with go 1.3+.
Ah, okay, so oplogReplay can return before all a previous stage's channels have been closed, but only if there's been an error in which case it doesn't matter.

Looking at the go blog post on this I guess this is what they do, so maybe I'll get used to the pattern after seeing it a few more times, I just find it a bit subtle (sorry, this isn't a criticism of your code, more a lamentation that using go routines + channels like this seems more complicated than it needs to be). Would it be better to write this code without go-routines and sacrifice the parallelism for readability?

Sorry for having so many questions