Config path fixes

[kzvezdarov]

This PR implements some of the feedback on how config files and paths are handled:

1. pwd is included in the search paths by default.
2. The README doc shows that ReadInConfig returns an error that can be handled.

Does not implement the suggestion that filepath extensions become optional - this needs some consideration.

[kzvezdarov]

Merged

[didenko]

Hm... Defaulting to read config from the working directory may make exploits easier in general case. It becomes possible for an intruder to take advantage of other misconfigurations and cd to a directory with a malicious config before running the program which uses viper, thus potentially altering its behaviour.

IMHO including the current dir or not in the search path is a simple choice for the package user (3-4 lines like in your commit), yet has negative implications for those who want their systems hardened. As a library, it is detrimental to have this hardcoded feature.

Besides, given the diversity of environments where software may be deployed these days, this hard- coded "feature"'s unintended consequences may either lead to an unexpected failures when config names collide between utilities, be a logger noise, or, again, be a security threat. Working directory is not always obvious - nor every utility writer should make assumptions about it. What is a workdir on Google App engine off the top of one's head?

[kzvezdarov]

If the malicious intruder has obtained enough permissions to execute a program that uses viper, they don't even need to change to a directory containing a malicious configuration - they can just pass in everything as command line arguments.

This issue is probably the better place for this discussion: #69