Improve support for a read-only root filesystem

XDOCKER-417 made the startup configuration work when the container runs with a read-only root filesystem, but two things are still missing for that mode to be fully usable.

LibreOffice does not start

With a read-only root filesystem, LibreOffice fails to start even when everything else is mounted correctly, so office import and export are unavailable:

ERROR o.j.l.o.VerboseProcess \- \(process:276\): dconf\-CRITICAL \*\*: unable to create directory '/root/.cache/dconf': Read\-only file system.
ERROR .l.o.LocalOfficeProcessManager \- Could not start the office process.
Caused by: org.jodconverter.core.office.OfficeException: Office process died with exit code 1

It needs both /tmp and the home directory of the container's user (/root) to be writable. Verified: with a tmpfs on /usr/local/tomcat/logs, /usr/local/tomcat/work, /usr/local/tomcat/conf/Catalina and /root but not on /tmp, the office process still dies; adding /tmp makes it start ("Open Office instance started").

The image could avoid requiring those two extra mounts, for instance by pointing HOME (and the LibreOffice profile) at a directory inside the permanent directory, which is writable by definition. Until then, the mounts are the workaround and are documented at https://www.xwiki.org/xwiki/bin/view/documentation/xs/admin/installation/methods/install-xwiki-docker/configuration/readonly-root-filesystem/

The error when a configuration file is not writable is not actionable

Bind-mounting hibernate.cfg.xml, xwiki.cfg and xwiki.properties is mandatory in this mode, because the entry point rewrites them from the environment variables. Forgetting one (or putting the files in the permanent directory instead, which does not work either) produces only a bare shell error and exit code 1:

/usr/local/bin/docker\-entrypoint.sh: line 66: /usr/local/tomcat/webapps/ROOT/WEB\-INF/xwiki.cfg: Read\-only file system

Nothing tells the user what to do. The entry point should detect that the target file is not writable and say so, naming the file and the fix.

While there, the temporary copy is left behind when the restore of a truncated target fails (a full filesystem): set -e aborts the function before its rm -f runs, and for hibernate.cfg.xml that copy contains the database password. The restore should be best-effort so that the cleanup always runs.