Simply and clarify the secret fetching process

[broamski]

This PR simplifies the secret fetching process with the introduction of SecretDefinitions, which contain relevant data around fetching a specified set of secrets.

Externally, a Secret Definition is defined via: VAULT_SECRET_THING=my/vault/path/to/a/key either with a corresponding DAYTONA_SECRET_DESTINATION_THING=/path/to/output or a -secret-env argument. Please note that the suffix is no longer required to match the final key name in the vault path.

Before this change, note that the suffix THING in VAULT_SECRET_THING was required to match the key name of the vault path:

VAULT_SECRET_THING=my/vault/path/to/a/thing
DAYTONA_SECRET_DESTINATION_THING=/path/to/output

# the following would not work:
VAULT_SECRET_THINGY=my/vault/path/to/a/thing
DAYTONA_SECRET_DESTINATION_THINGY=/path/to/output

This PR introduces arbitrary suffix identifiers:

VAULT_SECRET_WHATUP=my/vault/path/to/a/thing/called/hello
DAYTONA_SECRET_DESTINATION_WHATUP=/path/to/output

Secret Definition Decoder Guide

• VAULT_SECRET_: Singular Secret Storage Path Prefix
• VAULT_SECRETS_: Plural Secret Storage Path Prefix
• DAYTONA_SECRET_DESTINATION_: Secret Destination Prefix
• secretID-SUFFIX: The unique secret identifier that can be used to tie a Secret Storage Path Prefix to a corresponding destination prefix

Singular Secrets

• Singular Secret Declaration: VAULT_SECRET_<secretID-SUFFIX>=<SECRET-APEX>
• Singular Secret Destination: DAYTONA_SECRET_DESTINATION_<secretID-SUFFIX>=<FILE-PATH>

This PR also now enables support for using Plural Secret Storage Path Prefixes VAULT_SECRETS_<secretID-SUFFIX> with Secret Destination Prefixes DAYTONA_SECRET_DESTINATION_, which intended to deprecate the -secret-path command line flag.

Thank you @robison for authoring the additional tests.

[broamski]

@robison I updated the README to reflect these changes.