feat: put the log in the volume, so the container can be read-only

/var/log/letsencrypt was the only thing this image wrote outside its volumes,
and it is what stopped `read_only: true` from working. --logs-dir moves it to
/etc/letsencrypt/logs, beside the account key and the renewal config it
already keeps there.

The second gain is the one that matters more here. This is the service whose
breakage does not announce itself: a renewal that stops working is an expired
certificate sixty days later, and the log is what says why. On the root
filesystem it died with every container the registry replaced; in the volume
it outlives them.

Nothing else about the container needs to change to be confined. It never
changes user, the files it touches are its own, the ACME challenge is served
on 380 rather than a privileged port, and the HAProxy runtime socket it writes
to is group-owned by root -- so it reaches it by permission rather than by
CAP_DAC_OVERRIDE, and `cap_drop: ALL` takes nothing away. Measured on the live
relay: no file under /etc/letsencrypt or /etc/certificates is owned by anyone
but root, and the socket is srw-rw---- 1001:0.

Both READMEs say what a caller should set now, stop_grace_period included --
the entrypoint has asked for that one since it was written.

README.md

@@ -174,3 +174,13 @@ Container images are configured using parameters passed at runtime.
   same domain counts against them; test changes against
   `--server https://acme-staging-v02.api.letsencrypt.org/directory` before
   letting a loop retry every 12 hours.
+- **Nothing here needs a capability, and after `--logs-dir` nothing writes
+  outside its volumes.** The container never changes user, the files it touches
+  are its own, and the ACME challenge is served on 380 rather than a privileged
+  port, so `cap_drop: ALL` costs it nothing. The log used to be the exception:
+  `/var/log/letsencrypt`, on the root filesystem. It now goes to the
+  `letsencrypt` volume beside the rest of the state, which is what makes
+  `read_only: true` possible and what keeps the log of a failed renewal after
+  the container is replaced. Give the service a `stop_grace_period` too -- a
+  signal arriving while a pass is issuing is deferred until that pass returns,
+  and an issuance can outlast docker's ten seconds.