feat: add --env argument to inherit environment variable from caller

[Kamilcuk]

Hello. When passing secrets in environment variables to process under bwrap with a program that prints the command executed, for example in shell when set -x is enable, like debugging or various gitlab-ci tools, the bwrap command line will expose passwords to the logs.

This pull request add a simple --env option, that can be used like: bwrap --clearenv --env TOKEN to just inherit the value of environment variable whatever that value is, which will not show up in set -x output.

Thank you.

[smcv]

It is already possible to hide any bubblewrap option, including --env, by passing them in --args. For example, Flatpak does this. Something like this:

1. create a pipe (or a memfd or a temporary file with restrictive permissions)
2. write "--clearenv\0--env\0TOKEN\0swordfish\0" into the write end of the pipe, and close it (or write this into the memfd or temporary file, and seek back to the beginning)
3. make the read end of the pipe (or the memfd or temporary file) inheritable
4. add --args 3 to the bubblewrap command line, replacing 3 with the inheritable fd

[smcv]

I'm not sure how much effort we should be spending on adding "syntactic sugar" for things that are already possible. bubblewrap is a low-level tool that avoids having dependencies, so it will often make more sense for nice-to-have things to be done by its caller, rather than in bubblewrap itself.

[smcv]

If we add this feature as something separate from the --args mechanism that I described, I'd prefer it to be called --inherit-env or --inheritenv or similar. Related tools like Flatpak have an --env option that behaves like bwrap --setenv, so it would be really confusing to have an --env option with different behaviour.

[smcv]

If this is added, it should probably also valdiate that the argument doesn't contain =, which is the one non-zero byte that is not allowed in environment variable names.

[smcv]

Did you test this? Does it work? If it does, I'd be surprised.

If you previously passed --clearenv, won't the environment block already be empty? which means getenv() will return NULL and the new option is useless?