Define hierarchal configuration support

[melriffe]

Define and document how hammerhead's configuration can be specified and overridden.

This goes from configuration file, environment variables, to command-line arguments, flags, and parameters.

This must be clearly documented.

[melriffe]

The primary influence of my design for configuration is coming from "Build Awesome Command-Line Apps in Ruby 2", Chapter 6. This is a pragmatic programmer's title.

[melriffe]

From what I gleaned from the chapter: after default options are created, merge values from a config file before the command line is parsed.

I thought I read something about the user of ENV variables, but I might be mistaken.

[melriffe]

The question now is: can I use TTY::Config to support the idea of 'default' values and have them replaced before thor and CLI parse the command line?

I suspect the answer is no.

[melriffe]

I also might punt on this specific issue.

Side-Note: I wonder why I can't use a .hammerhead.yml file?

[melriffe]

There is one thing for certain: there are no default values for the Harvest credential information.

Because access to the Harvest API is central to this tool's operation, I feel even more compelled to punt on this issue.

[melriffe]

Maybe the path forward is this:

• when starting the tool for the first time and no config file exists, create a 'default' one with entries that clearly need to be replaced, and say a configuration file was created
• support a global option to use a different configuration file

This solves the problem of getting people to create a configuration file, with information on what needs to be set, and how. And it solves the problem I have: needing a configuration file for use that doesn't interfere with development and testing.