Add support for shell parameter substitution modifiers

[nthuemmel-scontain]

This adds support for the basic shell parameter substitution modifiers (which make sense for this crate), as described in https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02

Namely, it adds the following features:

• Use default values if a variable is unset or empty (${VAR:-default} or ${VAR-default})
• Error out of a variable is unset or empty (${VAR:?} or ${VAR?})
• Replace value if a variable is set (${VAR:+replacement} or ${VAR+replacement})

[allan2]

Thanks for this detailed PR.

Tasks for review:

• See if dotenv libraries in other languages, such as Ruby and go, support this functionality.
• POSIX-shell compliance is not a current goal of this library. I'd see if there is anything else not POSIX-compliant currently implemented, to see if it should be a goal.

If you or anyone has time to help with those tasks, that would be great. Otherwise, I will start looking into it in a week!

[nthuemmel-scontain]

• See if dotenv libraries in other languages, such as Ruby and go, support this functionality.

• Example for Ruby - gem dotenv - does not seem to support this: Only subset of shell functionality is supported bkeepers/dotenv#430
• Example for go - godotenv - does not support this: Variable in the form VAR="${VAR:-default}" does not parse correctly joho/godotenv#211
• Example for python - python-dotenv - does not support this: Does not execute default values, subshells, etc. theskumar/python-dotenv#402

Though the issues - and demand for such functionality - seem to be there ;)

• POSIX-shell compliance is not a current goal of this library. I'd see if there is anything else not POSIX-compliant currently implemented, to see if it should be a goal.

I don't think full POSIX-shell compliance should be a goal either, especially regarding the security implications of spawning arbitrary subshells. However, some features, like default values in variable substitutions, do not have these implications and are simply nice-to-have. As long as these features are properly documented and maintainable, it still makes sense to support them without full POSIX-shell compliance, from my perspective.
The second sentence ("I'd see if there is anything else not POSIX-compliant currently implemented, to see if it should be a goal") I don't fully understand, to be honest.

[allan2]

@nthuemmel-scontain, thank you for the detailed reply.

I'm going to sit on this for now, update the API, and then come back to this potential feature.

#19 related