Support standard docker individual secrets

[Rycochet]

🗣 Description

This adds standard docker secrets support for individual environment variables, allowing a server admin to pass values individually.

This follows the "standard" of <normal_name>_FILE for variables that support being used as secrets, and updates the readme with information on how to use it. The order of variables is alphabetical (as in the secrets file code).

💭 Motivation and context

This allows me to have my "secrets" in an env file outside my docker, and to allow them to be used directly without having to create a specifically formatted (json) file for them.

I have a server stack that I publish open-source, and individual secrets are a more standard way of doing this - the change was minor (although I added extra lines for debugging / logging).

Copied from the updated readme, note that this uses standard secrets, so it is just as possible to use an file as per the config alternative:

---
secrets:
  foundry_username:
    environment: "FOUNDRY_USERNAME"
  foundry_password:
    environment: "FOUNDRY_PASSWORD"

services:
  foundry:
    image: ghcr.io/felddy/foundryvtt:14
    hostname: my_foundry_host
    volumes:
      - type: bind
        source: <your_data_dir>
        target: /data
    environment:
      - FOUNDRY_USERNAME_FILE="/run/secrets/foundry_username"
      - FOUNDRY_PASSWORD_FILE="/run/secrets/foundry_password"
    ports:
      - target: 30000
        published: 30000
        protocol: tcp
    secrets:
      - foundry_username
      - foundry_password

🧪 Testing

This changes the entrypoint.sh file only, and does not have any side-effects beyond adding a _FILE suffixed alternative to already existing environment variables.

All variables

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow cisagov code standards.
• All relevant repo and/or project documentation has been updated
  to reflect the changes in this PR.
• All new and existing tests pass.

✅ Pre-merge checklist

• Revert dependencies to default branches.
• Finalize version.

✅ Post-merge checklist

• Add a tag or create a release.