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
Replace Java serialization of DaemonMsg by protobuf. See #1755

* Serializers for DaemonMsgCreate and DaemonMsgWatch
* Protobuf for DaemonMsgCreateProtocol, PropsProtocol,
  DeployProtocol, DaemonMsgWatchProtocol
* Removed unused MailboxProtocol.proto
* Fixed wrong serializeActorRef in DurableMessageSerialization
Create test-fixture for durable mailboxes. See #2061

* Improved DurableMailboxSpec for stand alone usage
* Changed build to publish DurableMailboxSpec in akka-mailboxes-common-test
* Changed documentation of durable mailboxes and added full example of
  how to implement a durable mailbox, with test
Imrovements from feedback. See #1755
Optimize remote serialization for the create from class case. See #1755

* Added FromClassCreator as special Function0 to be able to serialize
  class name as protobuf string