Improve code clarity

[dissolve]

getting a code climate score of 0.7, which is pretty abysmal.
While i don't agree with all of the rules they use, there is a lot of work that can be done to improve the readability of the code base.

[dissolve]

i have a branch called rubocop-cleanup which is tackling this.

However I wanted to discuss with @jgarber623 the thoughts on what defines a breaking change.

I am adding a new class that all of the results classes inherit from. technically someone could be testing for the name of the class's direct parent. It would be very foolish to do so, but this could potentially break things for them. It seems like a really obscure case that should not be done anyway.

[jgarber623]

Version numbers are cheap, so I'm totally fine if we want to play it safe and flag to users of the gem the potential for breakage (edge case usage notwithstanding).

Good refactoring on that results class, too. 👍

[jgarber623]

☝🏻 The implication there being that the next release of the gem would be 5.0.0.