Support YAML configs

[kentquirk]

Which problem is this PR solving?

• Fixes It's not possible to specify multi-valued fields (slices) in a .ini file #261
• Closes Honeytail 1.4.1 only supports a single value for AddFields in .conf #197 (we will not fix the .INI file problem, but deprecate .INI files instead)

Short description of the changes

It turns out that the library we use for parsing command lines and .INI configuration files has a bug where it just doesn't properly support multi-valued fields in INI files. The bug has existed for a while and the repository is stale.

I could have forked the library, fixed the bug, and then we'd have to maintain a fork forever since it seems unlikely to ever be fixed upstream.

Or I could have tried to switch to some other argument parser, but that would almost certainly have a whole collection of backwards-compatibility issues.

In addition, ini files are also pretty stale as a general concept. It seemed worthwhile to support a more modern format, and YAML is certainly eating the world as a config file format.

So I've done this:

• Chosen a popular yaml parser
• Decorated all of the configuration options with appropriate YAML tags to make sure that the configuration names are preserved
• Added a flag to write out a YAML config after reading the existing config (so that transitioning to the new format is easy)
• Added a flag to load a YAML config

Note that in the INI file world, because the config parser and the command line parser were the same entity, individual values in the config file could be overridden on the command line. But if you load a YAML file, all other config options are ignored.

No .INI files have been harmed in the making of this PR. All existing .INI behavior has been preserved -- this just lets us deprecate them and move to YAML instead.

The Honeycomb documentation also needs to be updated. I'll put up a PR for that soon.

[porterctrlz]

Bee still my beating heart :)

[MikeGoldsmith]

Looks good to me.

I've left one suggestion to add an empty yaml declaration for Fields in the csv options struct.

[MikeGoldsmith]

Should we add a yam:"-" for Fields too?

[kentquirk]

Definitely not "-" -- that would prevent the field from ever showing up. The rule I used was to add a YAML declaration only when the field name used in config didn't match the variable name, or when it should be suppressed. In this case, the field is called "Fields" and that's also the config value name, so a YAML tag naming the field would be redundant.