check sent revision when modifying user data

if the sent revision does not match the revision of the currently saved
user data, then somebody must have change them since we downloaded it.
The modification was thus not possible.
fix returned value
better return code handling

The paper creation did not return any value in case of success. This was
in contradiction with the general guidelines for the Rest Api.
fix return values
improved error message
Add contribution rules
typo
Add and register logging service

The OSGi specification describes a simple logging service that allows
bundles to easily log events. We implement this using slf4j and logback
as backend, one logger is instantiated by originating bundle.
Move config to common module

The configuration module does much more than just configuration now (and
will do even more soon). The commone name is more appropriate.
Add short description for new module

The `blue-common` module not mentioned at all in the README, which is
bad. If we already start to have undocumented modules and features, I am
not sure the project will be worth anything in a few months.
Add commit status
Move more utilities

Common interfaces and utility classes belong to the common module if
they are not related to Http stuffs or core features, such as email
templates
Use logging service

Instead of directly instantiating an slf4j logger, we use the registered
OSGi logging service, which should actually be better.
filter OSX temporary files out

.DS_Store file should *NEVER* be committed!

[ci skip]
Add logger to BlueLet

A request handler takes a logger to keep track of events that happened
during request processing.
The next step is now to actually log stuffs everywhere where there is a
TODO (and probably a lot more other places) and to add standrad logging
configuration that logs into files.

What would be interesting is to have something like `PaperLoggin` which
logs stuffs in a paper specific logger (e.g. in a specific log file).
Maybe the SiftingAppender class of logback can be used to implement this
feature in the slf4j way.
We must also see how this can integrate with the OSGi log service.
Add scenarios for paper list retrieval

This allowed me to fix a small serialization bug. Testing is good!
Fix build

I accidentally committed some stuffs from another branch, I should have
reload my sbt settings before testing...
Extract commonly used data

The `SomeUsers` and `SomePapers` can provide a bunch of users and papers
that can be used by any scenario. This avoids the need of recreating
such data in several scenarios
Fix annoying recurring bug

headers must be written before response body. For example, setting the
status code after having written the response body will issue an error.
By making the `writeJson` method return `Unit` we cannot chain the calls
after this one, which avoid stupid bugs that were to be found at several
places in existing code.
Add some user data scenarios