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+.
So I thought about removing all channels, but essentially what we want to happen in this code is a pipeline in that we want to stream operations from the file into our database, with a few transformations along the way.

Now, you can write a pipeline without channels, but this is one case where I think that channels are the right abstraction.  The code (especially the channel management) seems a lot more readable to me than the old code, but that may just be because I've spent a lot of time looking at it.  The part I really don't like is the batchOps function.  That seems like a place where channels aren't really what you want (not to mention the batch size is actually controlled in the previous stage of the pipeline with the buffered channel size...).