Multi-thread synchronization, fixed jUnit tests, reformatted code

##Changes:
###Synchronization:
>Methods block on methods that cache data (Ticker, OrderBook, Trades, AccountInfo).
>Deconflicted tagging in requests, made sure each request will (pretty much always) have a unique code.
>`doNewRequest` method now checks for both expected `EventType`, as well as expected `tag`. This should prevent cases where multiple threads requesting the same method could get confused by which reply is for which call.
>CoinfloorDemo2 now shows simultaneous calls of 5 threads for the exact same method, with the same variables, but doesn't get confused. This was done regarding @whitslack 's comment about serious bots needing to multithread. No synchronization needed front-end; it's all done back-end now.

###BaseWebSocketExchangeService (and related classes)
>WebSocketEventProducer now properly handles split frames in cases where data is too large to fit in a single frame.

###Coinfloor classes:
>All String literals of `"BTC"` or `"GBP"` changed to enum type, methods added to convert Strings to enum types (for generic DTOs, which use strings)
>`TimeUnit Sleep` call removed. `Blocking peek` still kept, since that's the only way I could think of to give all method calls a chance to check if the next event is theirs. Instead of sleeping, it's waiting on the `systemEventQueue`, which notifiesAll when a new event is added.
>`serverNonce` from welcome message is now cached in `CoinfloorEventHandler` during `handleEvent()` call, is retrieved by `authenticate()` method in `CoinfloorStreamingExchangeService`

###CoinfloorDemo2 classes:
>Authenticate shown after watchTickers() call as example. 
>Creates multiple threads for data requests, purposely synchronizes the requests to fire off at the same time as a worst-case-scenario. (5 should be enough?)

###Other:
>Updated DTO jUnit tests, (almost?) all of which were not updated after the scaling issues, and thus failing.
>Formatted everything according to Xeiam code formatting rules


##Comments:
Wow. I never realized how troublesome it would be to catch split frames, rejoin them, then treat it like a normal message. The `WebSocketImpl` used by the `WebSocketClient` in `org.java_websocket` doesn't cater for this possibility at ALL. There's pretty much no way of knowing when a frame is the last in a set of continuous frames. I had to use a crude workaround, checking the length. It will fail if the last set of data fits EXACTLY into the max buffer size, but that seems unlikely. Any thoughts or improvements on this aspect would be especially appreciated.