issue #2 - Storage manager is now common for every actor

It is created in dispatched instead of in every actors.
cosmetic fixes
issue #2 - synchronization handles multiple files

Until now, a synchronization actor could only handle one file. With this
modification, such an actor can now deals with all synchronized resources given
a paper Id. Each document is to be carried in the synchronization message.
add unit testing of ResourceDispatcher

Update to akka-osgi/testkit 2.2.1
fix bug in ResourceDispatcher thanks to unit test

on actor creation (first "Join" message). the user was not counted in the user
map.
issue #2 - add unit testing for Edit command parser
issue #2 - fix bug in EditCommand parser

'number' parser definition was missing .r operator.
issue #2 - remove unused constructor parameter for SyncActor
issue #2 - add simple unit testing for synchronisation actor

This is more a skeleton than an actual unit test, but anyway, there is some work
here that has to be taken into account.
issue #2 - add some logs in SyncActor

Since it is hard to trace what went wrong in the unit test, add some logs
For the moment, limited to delta command processing.
issue #2 - fix update of serverShadowRevision in SyncCommands processing

The response sent to the client was using the given, unchanged
serverShadowRevision, instead of the new one, computed in the flushStack()
function.
issue #2 - improve unit-test: send other delta after first one
issue #2 - fix bug in Synchronization Actor

the view representing the document of the client was not saved
issue #2 - fix EditCommand parser

Edits commands are separated by a tabulation ('\t' character). The parser was
using the incorrect form "\t", which caused it to no be correctly processed.
Add corresponding unit test.
issue #2 - add exception handling on DMP method invocation

A call to the DMP.diff_fromDelta() method would raise an
InvalidArgumentException if the given delta length
does not match the shadow length.
Fix this by enclosing this call in a Try construction.
issue #2 - add map for storing existing Document objects

A Document object is the server version of the text being worked on.
Previously, this text was loaded from the disk every time a new client sent its
modifications, which was incorrect (and lead the loaded document to be empty if
it was never stored before). Now, we use a map to store in-memory representation
of the document, shared among all connected clients (working on _this_
document).
NB: thanks to the Actor system, it is not needed to take care of any
synchronisation means. All calls concerning a paperId are processed sequentially,
so there is no concurrent access to the document map nor the document content.
issue #2 - new unit test and code improvements

In this new unit test, a Synchronization message is sent from two different
clients, for the same empty document. The resulting document shall have both
edits from both clients, and the second client should get the edits of the first
client in the server response.