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.
Start the status checker when the river is merely administratively disabled

A later REST request can be issues to start the river.
Do not force the river status in #close()

When we restart the river should come up in the same status as it was before, to switch a river
into the "stopped" state it must be explicitly done so using the REST API.
Change #internal{Start,Stop}River() to package protected

These methods aren't for external usage, but rather form a contract with the StatusChecker thread only.
Make it clear that "disabled" means "nothing will happen now"

Suggested-by: @benmccann
Fix the error messages to talk about "stop", matching the info message in the beginning.
Use a separate thread for starting up the river

The river status now changes from (nothing) to "START_PENDING" in the ES river startup code, to
"STARTING" while the startup thread is working on setting up the river, to "RUNNING" when the slurper/indexer
threads are active.

The process for stopping the river is unchanged up for the interrupting of the startup thread, should one be around.

The status checker avoids sending multiple start requests, and #internalStartRiver() ignores the request
when there is a non-null startupThread.
Use a separate logger for the StatusChecker

This helps distinguishing the logging from the checker about starting/stopping the river
from the actual information that the river is doing that.
Improve the logging

* unify the way we talk about the river
* use "begin of operation" and "end of operation" log statements
* move some log statements to more logical places

Suggested-by: @benmccann
Merge pull request #407 from Collaborne/split-river-start_stop

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