feat: standalone certificates for containers without VIRTUAL_HOST

[JamBalaya56562]

Implements the feature proposed in #1128 (standalone certificates from LETSENCRYPT_HOST alone, e.g. for an SMTP container that is not proxied), using the approach suggested there: the template now detects containers without VIRTUAL_HOST / VIRTUAL_HOST_MULTIPORTS instead of routing every certificate through add_standalone_configuration, so proxied certificates keep the exact same code path and two-container setups without a shared /etc/nginx/conf.d are unaffected.

• letsencrypt_service_data.tmpl renders a new ACME_STANDALONE_CONTAINERS array listing the identifiers (SAN and single-domain forms) of containers that have an ACME_HOST / LETSENCRYPT_HOST but no VIRTUAL_HOST / VIRTUAL_HOST_MULTIPORTS.
• update_certs runs those identifiers through the existing standalone challenge configuration pre-pass (shared with letsencrypt_user_data certificates); the post-issuance conf removal and cleanup paths are unchanged.
• Since the identifiers are real container IDs, LETSENCRYPT_RESTART_CONTAINER works for these certificates, which the letsencrypt_user_data route couldn't offer.
• New standalone_container integration test: a LETSENCRYPT_HOST-only container gets its certificate through the standalone flow, and a proxied container is never classified as standalone.
• Documented in docs/Standalone-certificates.md.

Verified locally by rendering the template with docker-gen against dummy containers (SAN, single-domain, VIRTUAL_HOST and VIRTUAL_HOST_MULTIPORTS variants): only the containers without a virtual host are listed in ACME_STANDALONE_CONTAINERS.

Supersedes #1128 if accepted — credit to @pini-gh for the original proposal.

🤖 Generated with Claude Code