feat: allow finding origin of value

[phm07]

This PR proposes a new function viper.Origin that allows finding the origin of a configuration value.
It might be used for following use cases:

• Check if a value was changed by the user (viper.Origin(key) < viper.ValueOriginDefault)
• Display origins to the user (could be useful if a value is unexpectedly shadowed)
• Debugging and testing

The implementation is largely based on (*Viper).find, but instead of returning the option values, it returns a viper.ValueOrigin based on the current code path.

Alternatively, you could also return a ValueOrigin from (*Viper).find and then expose that through viper.Origin. This way there would be less code duplication. Let me know if you prefer this approach.

What still needs to be done/discussed:

• Tests for the implementation
• Documentation
• The ValueOrigin type
  • Is it too clunky? Values like viper.ValueOriginOverride are quite long.
  • Use int or string as underlying type? string allows for easy human-readable output, int allows for comparisons inside of the hierarchy (see above). Maybe add (ValueOrigin).String()?
  • If int is used, the order of the values

[CLAassistant]

All committers have signed the CLA.

[github-actions]

👋 Thanks for contributing to Viper! You are awesome! 🎉

A maintainer will take a look at your pull request shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️