first step towards TestConductor

- it compiles
- server side ("Conductor") functions almost there
- client side ("Player") sketched, but missing network failures
- no internal failure handling whatsoever, waiting for Project DeathWatch
- not yet possible to shutdown, need to kill VM
- next step is to hook into the NettyRemoteSupport for failure injection
porting to 2.0, making it compile: UNTESTED!
TestConductor: convert to Akka Extension and add test

- make start-up synchronous and explicit for client and server
- server can be queried for actual port, client requires explicit port
- simple multi-jvm-test for verification of TestConductor barriers
fix bug in FSM when manually rescheduling non-recurring timer, see #2043
integrate NetworkFailureInjector and add first test

- rework socket pipeline to transform protobuf into case classes and
  back
- introduce NetworkOp messages for that purpose
- make API asynchronous (because it is, really) and add Done
  notification for all server operations; enter(...) is still
  synchronous, because that is its only purpose in life
- factor out mkPipeline in NettyRemoteTransport, enabling the very slick
  TestConductorTransport (essentially a one-liner)
- switch NetworkFailureInjector from Channel{Up,Down}streamHandler to
  subclassing SimpleChannelHandler, because otherwise deadlocks
  occurred, not sure why (but SCH is the recommended way from the netty
  docs, so there may well be a reason)
add previously forgotten TestConductorTransport
implement more precise bandwith throttling

- will keep track of theoretical packet boundaries and send on timer
  tick or send request according to actual time
- will split packets if calculated release time is >100ms into the
  future (configurable) to simulate proper trickling
optimize partial message scheduling

- split only right before send (if necessary)
- do not reschedule Tick if that has already been done, because the head
  of the queue does not change so the old data are still correct
- make test a bit less fickle wrt. timing
wait for initial crew before starting the party

- the Controller is started with the required initial number of
  participants
- if that is >0, it will hold off sending Done to the clients until that
  number has connected, then set it to zero
- if that is <=0, send Done back immediately upon connect
fix BuilderParent in generated TestConductorProtocol.java
rename mkPipeline => createPipeline
handle barrier failures better
Adding a doc diagram for the Test Conductor Extension
break out TestConductor stuff into akka-remote-tests project
scaladoc for TestConductor
add some tests for BarrierCoordinator and Controller
wrap up MultiNodeSpec, see #1934 and #2063

- restructure message classes in sealed traits according to message flow
  direction and include confirmed/unconfirmed status in the type
- add GetAddress query for obtaining the remote transport address of
  another test participant
- add reconnects to Player
- add small DSL with runOn(node...), ifNode(node...)(<true>)(<false>)
  and node(<node>):ActorPath
- rewrite TestConductorSpec to use that DSL and run within a single test
  procedure instead of separate NodeX classes
- hook up that test into current multi-jvm infrastructure temporarily
  for testing (will use Björn’s new remote-multi-jvm stuff later)
add utility for fixing up broken PROTOC code (and apply it)
switch to Björn’s new multi-jvm setup (i.e. remove system properties)
switch MultiNodeSpec to use RoleName type when referring to participants

- also add MultiNodeConfig base class for conveniently declaring a test
  setup including roles and (node specific) config settings