Allow the Django secret key to be set via DJANGO_SECRET_KEY env var

[pimzand]

Fixes #747.

Problem

contrib/docker/entrypoint.sh rewrites SECRET_KEY in djangosettings.py on every container start. Where /etc/frepple is persisted (Linux install, docker-compose named volume) this is a harmless first-boot stamp — once a real key is written the placeholder-anchored sed no longer matches. But the official Kubernetes manifest in contrib/kubernetes does not persist /etc/frepple, so the config dir resets to the shipped placeholder on every pod (re)start and a fresh key is minted each time — invalidating all sessions and rotating SECRET_WEBTOKEN_KEY (the Odoo SSO bridge). The issue explains why simply persisting /etc/frepple on Kubernetes isn't a clean answer.

Change

Let the entrypoint honor a DJANGO_SECRET_KEY environment variable: use it when set, fall back to the existing random key when unset. This is purely additive — with the variable unset, behavior is identical to today, so no existing deployment (Linux, docker-compose, current Kubernetes) changes. It keeps the pod stateless and /etc/frepple image-owned and writable, and lets SECRET_KEY be supplied the same way POSTGRES_*, ODOO_*, and FREPPLE_* already are.

• contrib/docker/entrypoint.sh — honor DJANGO_SECRET_KEY when set. The substitution still only matches the shipped placeholder, so an already-stamped (persisted) key is never touched. Reworked from sed to a small Python snippet that injects the value via repr(), so arbitrary key characters can't break the substitution.
• contrib/kubernetes/frepple-deployment.yaml — set DJANGO_SECRET_KEY from a new frepple-secret Secret (ships a placeholder value with a generate-your-own note).
• doc/installation-guide/advanced/kubernetes.rst, doc/installation-guide/docker-container.rst — document the variable and the Secret.

docker-compose is left unchanged — its named volume already persists the key.

[pimzand]

Superseded by #749. The right fix is to persist /etc/frepple in the Kubernetes manifest (parity with how docker-compose already persists it on a named volume), not to add a DJANGO_SECRET_KEY env var — the rotating secret was only the visible symptom; installed apps, scenario count and display settings are lost on pod restart too. See the explanation on #747.