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.
Not sure that makes sense if they're only used internally. I would only expose them if needed by collaborators, and right now, the only 'collaborator' is `bin/reek`.