Rethinking configuration.

This addresses #351 

With this pull request there are 3 ways of passing `reek` a configuration file:

1. Using the cli "-c" switch
2. Having a file ending with .reek either in your current working directory or in a parent directory (more on that later)
3. Having a file ending with .reek in your HOME directory

The order in which `reek` tries to find such a configuration file is exactly like above: First `reek` checks if we have given it a configuration file explicitly via CLI. Then it checks the current working directory for a file and if it can't find one, it traverses up the directories until it hits the root directory. And lastly, it checks your HOME directory.

As soon as `reek` detects a configuration file it stops searching immediately, meaning that from `reek`'s point of view there exists one configuration file and one configuration only regardless of how many ".reek" files you might have on your filesystem.

A word regarding the features:

When fixing the failing features I improved them while I was at it. For instance a lot of the features were targeting "masked" samples even though the "masking" was totally irrelevant for the feature itself and thus highly misleading.
Strictly speaking this wasn't necessary for this PR but I believe we should reeks OOD whenever we come across something that isn't good enough yet. And from an OOD POV (at least for me) it makes sense to expose those attributes for reading.