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.
Hmm. I guess with our small-but-many river situations not just waiting the few seconds would be stupid, but assuming a bigger river indeed one might rather prefer responsiveness of the administrative actions than being forced to wait.

I think it should be possible to offload the actual start procedure into a separate thread, maybe combining it again with the CollectionSlurper functionality. A possibly simpler version would be to use a thread pool here, and cancel the future of the task. Need to look a bit into that, my gut feeling usually wants to avoid more explicitly managed threads :)