Support fixed rate oplog replaying (ops per second)

This change adds an interface for controlling the rate at which we apply
op logs. Theoretically this interface could control the rate at which
more generic things are done. Though it's similar to the leakybucket
abstraction we already have, the relative rate ideas we have didn't
cleanly map onto the leakybucket so I thought this new interface was
useful. I considered doing the interface slightly differently -
returning a time to wait until applying the operation instead of just a
boolean. I ended up going with this because it a slightly simpler
interface, but I could probably be convinced the other one is better.

This change also adds to implementations of the interface. The fixed and
relative rate controllers we want for oplogs. It also adds a new command
line parameter to control which rate controller we use in the replay. It
defaults to the fixed rate.
The downside of this is that it all the controller implementations can only take in `speed`. If you're implementing something as complex as a plugin system, and thinking of these as plugins, then everything would have a way to specify custom inputs, which isn't possible here. A plugin system is probably way more complex than what we want, as well.

The way the Go standard library would organize this would be to make them namespaced, e.g. you'd have "ratecontroller/fixed" packages and "ratecontroller/relative" packages, each with it's own `New` function that returned something implementing the `Controller` interface.

I don't care much, though - I think it's fine as-is if you don't want to do that.