New HLet hierarchy for async/sync requests

This is not perfect yet, and code is duplicated. Actually, we should
investigate on how to make the authentication feature stackable and how
to make it not impact the existing lets. Moreover, currently the
authentication is basic but when we will support OAuth in addition to
cookie based authentication the authentication logic will become a bit
more complicated (or not?). Let's see if this scales and is usable at
all.
Wrap property in a `Try`

Depending on how the resource actor is created it may raise an error. In
such a case it cannot be created and the exception should not simply
escalate. By wrapping it in a Try, we can properly handle error cases.
Move actor system to common bundle

The actor system may be used by a lot of bundles, so this is a common
stuff. Actually the more I am thinking about it, the more I want to
register everything but the core http api in the common activator.

The core bundle is just the core features that allow \BlueLaTeX to
manage people, sessions and papers. Nobody depends on it directly,
everybody needs the common features.

And if somebody needs this, lets just declare it a dependency when
needed. But this was of organizing stuffs looks better to me.
First draft of the compilation feature

For now the compilation feature includes:
 - a `Compiler` interface is added to allow for extending \BlueLaTeX
   with new compilers,
 - the dispatcher creates the compilation actor with settings saved in
   the database, or create default settings if not already present,
 - the compilation actors schedule compilation tasks depending on the
   configured interval.
 - paper compilation
 - paper compilation channel
 - compiler settings retrieval
 - compiler settings modification
 - png file downloading
 - pdf file downloading
 - log file downloading
 - cleanup working directory

Of course this comes with some modifications in the general Api of
\BlueLaTeX and how it is used. It improves with each new feature
implemented, and I really hop we will reach some stable point really
soon,

The compilation stuffs are deployed only when the synchronization server
is registered
Refactoring: use custom UserInfo type

For the moment the `common.UserInfo` type is just an alias for the
`sohva.UserInfo` type. But this may differ in the future. It does not
cost anything to use an alias here in this case, and make future
changes easier (when the code base will be much much larger).
Persist paper files before compiling
add first scenario
Remove useles RichService class

All in all, the `RichService[T]` is just an `Option[T]`...
First skeleton for hooks

Add hooks that are called when user and paper are created or deleted.
This allows modules to add actions, e.g. the compilation module creates
the compiler settings when a paper is created.
Fix header bug

Same as before, the headers were sent after the content, which simply
does not work...
Add a way to get the list of available compilers
Integrate changes in the synchronization server
Complete implementation of hooks

Hooks are called when paper and user are created or removed.
fix compiler modification saving

 - fix validation function
 - fix revision when document is patched
send join/part messages
Add `pdflatex` compiler

This is the default compiler that compiles paper using `pdflatex`