Implement support for config includes/imports

[thomdixon]

This adds support for inheriting/importing/including configuration
files by specifying a config key which, when encountered, is to be
treated as a list of config files to inherit from and be merged with the
source config file, establishing a config hierarchy.

This allows developers to have e.g., a "base" configuration which
is then imported by their "beta" config or "production" config to
be overridden or extended.

As an example, one can call SetConfigIncludeKey("includes") and then
include config files in their e.g., YAML config as follows:

includes:
  - base

which will search for base.yaml in the specified config paths, read it, and merge the current config into it.

Naturally, this only works on local config files and is implemented
with that restriction in mind. Moreover, writing out the loaded config
should correctly output the final merged config, sans the specified
config include key (since it wouldn't be of much use).

All existing tests pass and new tests were added for this feature.

[CLAassistant]

All committers have signed the CLA.

[JingboWangGoogle]

I am a Google intern working on OpenTelemetry Collector this summer, specifically the metrics transform processor, and it uses viper for loading config files. One of our use cases is that we have a base configuration, and we also have a temporary configuration file for third party supports, which will undergo changes or removals, so keeping these two separate would be our cleanest option. This functionality is actually great for our use case there!

[sagikazarmark]

Viper v2 will come with multiple configuration sources. In v1 you should be able to use things like MergeInConfig and manually read those files if necessary.

I don't think this should be added to the core right now.