feat: [V2] Rewrite config code without Viper

[kentquirk]

This is bigger than I wanted it to be, but there were a lot of tests that needed to be updated. I did rework a number of tests to simplify the creation of sample configurations, and eliminating Viper required the creation of a couple of new functions.

I feel like this has significantly simplified the config code and made it easier to understand and maintain. Please read the comments below before reviewing the code.

Elements of this project:

• Separate cmdline/env from configuration
• Find/write appropriate libraries to do all the tasks of loading cmdline, applying defaults, applying the cmdline, and validating afterward
• Replace viper with these new libraries within the same config structure
• Do the automatic reload (I wasn't going to do it for this PR but it breaks lots of tests, so I'm adding it).

Out of scope for this PR:

• Change config internal structure and helper functions
• Change sample configs and test code to YAML

How to tell if we're done?

• Passes all its tests
• Existing config files can still be loaded

Which problem is this PR solving?

Viper is a strongly opinionated configuration tool. That can make it easy to start building something, but because in this case "opinionated" means "there's one way to do it and no easy way to change that" it can (and has, in my experience) become more and more of a maintenance problem as a codebase ages.

Refinery needs a significant rework to its configuration model:

• Its many config values should be broken up into more sections of related items and fewer at the root level
• This will allow better unit testing without mocking the entire config in a single object
• The relationship between command line, environment variables, and configuration should be clear and unambiguous
• Default values should be clear and unambiguous
• Since some configuration is reloadable at runtime, how that happens should be clear
• We want to support loading config from a remote source
• We want YAML-first configuration so that it's easier to work in a Kubernetes world
• We want to enable config to be loaded from a URL
• Full validation of configuration should become possible, including extra or mistyped names (this PR will not include this but will enable it).

Some of these things are possible with viper, but not all of them, and in practice Viper makes balancing these things difficult.

Short description of the changes

This PR introduces some new tools to enable us to remove Viper:

• Configuration defaults are applied by a new library (creasty/defaults) that simply examines default struct tags and applies them when called.
• A new library (jessevdk/go-flags) is used to handle command line and environment variables and map them onto a struct. This enables clear control of a separate struct (CmdEnv) for these things.
• Items in the configuration that are tied to the CmdEnv struct are given the cmdenv struct tag in the configuration that identifies them.
• A reflection-based function applies these cmdenv tags to configuration values at the appropriate time (after the configuration is loaded and defaults are applied).
• We continue to use the existing validation library (go-playgroundvalidator) to express simple post-loading validations
• These tools also allow loading a config from a URL instead of a file
• There's a new config value ConfigReloadInterval that controls the timing of reloads; if the hash of the contents is the same, no reload occurs. This is a timed reload rather than one that depends on operating system notifications. A future PR will allow a cluster of refineries to share knowledge of a configuration change.

The result is that entries in configuration structs can have up to 3 primary tags:

• default sets default values
• cmdenv when they need to be configurable on the command line and in the environment
• validate expresses validation rules

[kentquirk]

Tests broke; will fix.