Java 1293

## Core changes

* InternalStreamConnection - now handles the pipeling and queues up pending reads and writes and processes them when the stream is not in use.

* sendMessage - blocks waiting for the write lock before sending
* receiveMessage - blocks waiting for the `messageId` to arrive in the Message queue and / or reads from the stream and adds messages to the queue.
* sendMessageAsync - queues up messages to be written and then calls the process method
* receiveMessageAsync - processes any Messages on the Queue that have callbacks and then reads from the stream and adds the Message to the queue on completion.



### Features todo:

- [x] Support Multiple writes at same time
- [x] Support Multiple reads at same time
- [x] Sync support for writes and reads
        
### Tests 
- [x] Mock stream.
- [x] Test multiple writes - with mocked stream to confirm it waits
- [x] Test mix of async and sync reads / writes
- [x] Test out of order responses
- [x] Multiple threads hammering the connection....
See message in sendMessageAsync regarding initializeCalled. There is a race condition between these two. If it was just this one, then it's possible that two consecutive calls end up inside the if statement at the same time. Haven't looked at the protection of those methods, but it seems like we need a lock here to prevent code from continuing until initialization is complete.