Refactor SmellWarning.

### Status:

All tests are passing now.
@mvz review please.
In reference to : https://github.com/troessner/reek/issues/322

--------------

### Summary of all changes:

- I got rid of those awful SMELL_CLASS and SMELL_SUB_CLASS constants and introduced proper instance methods instead
- Introduced consistent naming. Now it's "smell_class" and "smell_sub_class" everywhere, not "smellclass", "subclass" and all other possible combinations
- Removed a couple of weird inconsistencies, for instance the DuplicateMethodSmell specifically checked for the number of calls to print out "twice" instead of "2 times". No other smell detector did this and the usefullness of this code in general was questionable, so I removed it.
- Removed SmellDescription again since now this is all handled in the SmellWarning or SmellDetector
- Made the yaml presentation of our smellwarnings leaner and better readable
- Reduced the initializer of SmellWarning to ```def initialize(smell_detector, options = {})``` and properly formatted all calls to it
- Dissolved unnecessary and confusing methods like: https://github.com/troessner/reek/pull/328/files#diff-3cebf3ed8bf2e7bb8722230d83a5261fL29
- Introduced factories. I believe we really need to rewrite and refactor big parts of our spec suite and this is first step in this direction and we can and should introduce those everywhere gradually to make our specs better readable.
- Removed a couple of specs that were just over-the-top: https://github.com/troessner/reek/pull/328/files#diff-3effa8810e8fa5e585292d52fd8ad2f1L121 
- Removed a couple of specs that shouldn't be there: https://github.com/troessner/reek/pull/328/files#diff-e1d2ab95ea1f1960578653dc80c68c32L79 - this detector is the only one checking for the yaml format which is not his responsibility.
- Made factory_girl, pry and byebug available in our specs by default

--------------

### Regarding the tests:

Unfortunately our spec suite is more often than not absolutely suffocating. Sometimes it costs significantly more time to deal with our incredibly tight to the implementation coupled spec suite than with actually writing code and I'm a little fed up with it. 
I actually didn't do a couple of other bigger refactorings in this pull request just because fixing the regarding specs would have been in incredible pain in the ass.

I believe our spec suite is so suffocating right now for the following reasons:

- Our specs are often mirroring the implementation. We have so many specs testing things like output that one change in the output requires you to change a dozen tests
- Our specs are often duplicates or at least overlapping with other specs.
- The level of detail for an output format is over-the-top for me. It's not like reek is a tool for emitting floor plans for nuclear facilities. Getting all those format specs right is a huge pain in the ass and I can't see a real reason for this (besides the "oh my god, it's not spec'ed" one)
- A lot of them are just in bad shape. There are so many specs that declare some instance variables at the top and use them 100 lines below in combination with other instance variables that come from 20 lines above.
- Not using factories properly or at all makes our specs incredibly hard to read because you have to cut through all that noise.

I am convinced that our spec suite right now is part of the problem, and not of the solution.

I'm going to refactor those specs step by step in follow-up PRs

--------------

### Things I left untouched

There were a couple of things I left untouched in this pull request because they would have required huge changes:

1.) Getting rid of the class methods "smell_class" and "smell_sub_class" for SmellDetector: https://github.com/troessner/reek/pull/328/files#diff-5b6de37fbe6e3791a90ceaf86e847935R58
2.) Getting rid of the gazillions of constants for the parameter keys that are floating around in almost every smell detector and that used and spread across our spec suite

I'll come up with separate PR's for those issues
Let's rather do that in a subsequent PR.