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.
I tend to be more lenient with attribute exposition if it's just for attr_readers since this makes it way more fun to poke around objects in console and such. But I also see your point so I removed the reader for "command" and "status".