Improve encoding layer

[sagikazarmark]

This is an attempt to further improve the encoding layer specified in #888 and introduced in #986.

Major changes introduced by this PR:

• Encoder/Decoder interfaces now accept map[string]interface{} instead of just interface{}. The rationale behind that change is that the encoding library is supposed to be used with Viper (it's not a generic library), so it's okay to make the interface Viper specific.
• Two additional codec implementations:
  • INI
  • Java properties
• Encoder/decoder registries are now instantiated per Viper instance. It's required for some codecs (INI, Java props)

The PR also adds some basic tests to the existing encoder implementations.

A couple notes and concerns regarding this change:

Both INI and Java properties require the key delimiter to do some key mutation magic. It's required because both file formats contain key-value pairs (unlike the more common formats like YAML or JSON where you can have more nested configurations). As a result, the codecs have to be instantiated per Viper instance (since the key delimiter can be changed on instantiation).

In Viper 2 this should be a separate configuration of the codec, not tied to Viper's internal key delimiter config to allow storing keys in different formats.

---

Another problem introduced by the Java properties codec is that it's actually stateful: Viper saves the properties structure so it can write back properties files preserving comments and order. This is problematic, because the interface itself is designed for stateless codec instances.

For Viper 2 I think we should drop this feature, because it makes things a lot more complicated. We can hack things around for Viper 1 (eg. create a codec for Viper 1 specifically or make statefullness optional). I can't think of any viable alternative than dropping this feature for Java props. It's not like the most actively used file format and we want to discourage saving config from Viper anyway.

To Do

• Make tests more robust based on examples in Viper tests (eg. test more INI features)
• Improve the Java properties codec
• Java properties will probably have to be added back to Viper, since codec registries can be reset. Not sure if it's a problem though. No need to reset codecs (for now).
• Implement a dotenv codec

Misc

Fixes #923

[serge-v]

do you have a plans to make the codecs pluggable like drivers in sql/database package? For example if I use only yaml I would import _ github.com/spf13/viper/codecs/yaml. So as a result I don't need to add json, hcl, etc dependencies into vendors.

[sagikazarmark]

That's the plan, but it probably won't happen before v2

[sagikazarmark]

I decided to merge this PR. We can always make changes to it before we finalize the API.