Add support for reading command-line options from file(s)

The users command-line app has a top-level command, whose name is <name>.

For example, if the user was creating a word count CLI, then their top-level command name might be wc.

ZIO CLI should examine the following locations to check for the existence of .<name> files:

1. The current working directory.
2. All parents of the current working directory.
3. The user's home directory.

So, in the wc example, if run from /c/Users/john directory, then ZIO CLI would look in the following locations for the existence of .wc files:

1. /c/Users/john
2. `/c/Users/
3. /c/
4. ~ (user home, probably /c/Users/john on Windows)

Then, ZIO CLI should concatenate these options, with user home having the lowest priority, and the current working directory having the highest priority (so, for example, you can override options in higher priority locations).

Then, ZIO CLI should utilize those command-line options when the program is run, and not require those options be specified. However, if any option is specified on the command-line, then it must override even the highest priority setting specified in the settings files.

An example, let's say wc has an option --line-ending. Then in the .wc file, there might exist:

--line-ending=\n

Then this would be the default line ending. The user would not have to specify it on the command-line. But if the user did specify it on the command-line, it would override the one in the file.

This new functionality should be documented in the help docs for the CLI. Moreover, all of the settings that are picked up from any of the files need to be printed out, so the user can understand exactly where they are coming from.

Start by tracing the users command-line app's option parsing and help documentation entry points; the issue names no files or tests. Done means options are loaded from the specified . locations with the stated precedence, explicit command-line values override them, their sources are printed, and the behavior is documented.