…le#117)

Motivation
----------

Many `containertool` options have default values set by environment
variables.
* if the option flag is set on the command line, the command line value
is used
* otherwise, if the option flag is not set, the environment variable
value is used
* otherwise, a hard-coded default is used

This pattern is quite convenient, but there are some drawbacks. For
example:
* the default value declarations complicate the definition of new
arguments.
* default values appear in the `--help` output: for some options, such
as default base image, this is desirable, but for others, such as
credentials, it is not.

Some options do not fit this pattern well. For instance, `containertool`
tries to detect the architecture of the executable it is packaging so it
can try to choose a compatible base image.
* if the architecture flag is set on the command line, that value is
used
* otherwise, if the flag is not set, the environment variable value is
used
* otherwise, if the executable is an ELF file, the architecture is read
from the file
* otherwise, a hard-coded default is used

The path to the executable is an option which is parsed by the argument
parser. It is not available when the parser sets up default argument
values, so it must be handled after the arguments have been parsed,
overwriting whatever the parser had set. This means that option handling
for this flag is split into two different places, which invites bugs.

Future changes to `containertool`'s configuration, such as supporting a
configuration file on disk, add further complications.

Modifications
-------------

* All command line arguments with corresponding environment variables
are handled uniformly, with defaults applied at the start of the `run()`
function

Result
------

No functional change, but maintenance and future enhancement become
easier.

Test Plan
---------

All existing tests continue to pass.
Handling defaults in this way allows future PRs to add unit or
integration tests which exercise argument parsing.

Motivation
----------

Many `containertool` options have default values set by environment
variables.
* if the option flag is set on the command line, the command line value
is used
* otherwise, if the option flag is not set, the environment variable
value is used
* otherwise, a hard-coded default is used

This pattern is quite convenient, but there are some drawbacks. For
example:
* the default value declarations complicate the definition of new
arguments.
* default values appear in the `--help` output: for some options, such
as default base image, this is desirable, but for others, such as
credentials, it is not.

Some options do not fit this pattern well. For instance, `containertool`
tries to detect the architecture of the executable it is packaging so it
can try to choose a compatible base image.
* if the architecture flag is set on the command line, that value is
used
* otherwise, if the flag is not set, the environment variable value is
used
* otherwise, if the executable is an ELF file, the architecture is read
from the file
* otherwise, a hard-coded default is used

The path to the executable is an option which is parsed by the argument
parser. It is not available when the parser sets up default argument
values, so it must be handled after the arguments have been parsed,
overwriting whatever the parser had set. This means that option handling
for this flag is split into two different places, which invites bugs.

Future changes to `containertool`'s configuration, such as supporting a
configuration file on disk, add further complications.

Modifications
-------------

* All command line arguments with corresponding environment variables
are handled uniformly, with defaults applied at the start of the `run()`
function

Result
------

No functional change, but maintenance and future enhancement become
easier.

Test Plan
---------

All existing tests continue to pass.
Handling defaults in this way allows future PRs to add unit or
integration tests which exercise argument parsing.