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.
>> What made you decide to make this a singleton?

Since "singleton" is such an overused term let's agree on what we're talking about. I assume you're talking about the design pattern like described on WP:

>> the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.

I believe this abstraction fits our use case here.

>> I tend to find them more trouble than they're worth.

I've had a couple of bad experiences with over-using this pattern as well but I believe in this case it is fitting.