Split the start/stop actions from the river start/close methods

The RiversService will invoke #start()/#close() when the river itself is started/stopped. However
we also have our internal status (controllable via REST, and driven by the StatusChecker), which is
semi-independent from that.

Split those two lifecycle actions:
River #start()/#close() now only manages the status thread itself
MongoDBRiver #internalStartRiver()/#internalStopRiver() is invoked by the status thread

This fixes first of all #406, as we're no longer deadlocking inside the initial listener thread. As a side-effect
it also fixes a potential inconsistency between the status of the river as seen by us, and the status of the river
as seen by the RiversService.
Sounds like you have the opposite setup that we do. We have one big river that takes > 24hr to index :-)

I think it'd be best to keep CollectionSlurper as a separate class. One reason is that I'd like to see us add unit tests (right now we only have integration tests) and it seems easier with it as a separate class. Using a Future rather than a Thread sounds like it could be nice =)