Create an abstraction for config loading

[sagikazarmark]

Configuration sources are hard-wired into the core of Viper. Similarly to encoding, not all sources might be necessary all the time, particularly remote sources, which actually pull in a large number of dependencies.

One of the goals of Viper 2 is lowering the number of dependencies and this is an area where we can do that, by creating a similar, library based solution to encoding.

Since every configuration internally is represented as map[string]interface{}, the interface could be as simple as:

type Loader interface {
	Load() (map[string]interface{}, error)
}

This would also be a step towards a better API.

Similarly to encoding, for the time being this should also be backwards compatible with Viper 1, so:

• the library should be in the same Viper module
• the library must only add (but at least retain) functionality
• the library should go under github.com/spf13/viper/internal for the time being

The internal library also allows us to compare the new library to the old implementation first, without exposing it.

[shaj13]

@sagikazarmark
let me know how I can help with v2, tried to push a commit to #772 but it's limited to collaborators.

[lucasoares]

Any timeline on this @sagikazarmark ?