Log4j2 logging backend

[rmader]

This adds log4j2 as logging backend. We don't need to make any further adjustments to the code, it's a direct drop in and we can continue logging with Log.getlog...

It's main benefit is the cache (by default 8KB), therefor reducing IO request significantly.
Especially on systems without ssds, this could improve performance alot.
It has also much more potential, like having a maximum filesize and gzipping of old logs, that we can enable later.

At some points in the loklak code, there's still direct prints (stacktraces for example) that don't use the log infrastructure yet. They're still logged to a new log file (stdout.log), but we can slowly move them all to using the log.

As this potentially impacts one-click deployments, I'd like to request help with testing them. Some of them probably expect us to write our log to stdout to be readable from their interface, so we might need to make adjustments on how we use them.
(scalingo for example has a log console. we have to check if the log is still written there)

• Scalingo
• Heroku
• Bluemix (has build issues atm, see Bluemix deployment failing #539, but not related to this)
• Docker cloud (uses default startscript and logfile)

Edit: scalingo, heroku and bluemix are now logging to console again as they did before. Docker cloud uses the logfile like before

Know issues:

• sometimes the last logs (after the termination signal) go missing on shutdown as the logger also get's shut down
• elasticsearch still uses an uninitialized log4j1 as it's logging backend, therefor not logging anything. I left this untouched, but we should maybe move it to use our general log, because it actually does have some interesting output, potentially helping us debugging things

[rmader]

@Orbiter @mariobehling If loklak.org uses the default installation, I'd be very interested if this has a meassurable performance impact on the server.
On my personal system it's hard to meassure, as it just doesn't get under heavy load