Gemspec: Move development deps to Gemfile

[olleolleolle]

This PR moves the development dependencies out of the gemspec and into groups in the Gemfile.

It also moves the version-dependent activesupport dependency into separated Gemfiles, so that the Travis build matrix targets can choose which activesupport version is for them.

By trying to leverage Bundler's platform support, we can get away from weird hacks in the gemspec.

In the Travis build matrix each Ruby version gets its dependencies pointed out to it using the gemfile: travis.yml feature. A gemfiles/ folder is supplied.

[michaelklishin]

What's the benefit of this?

[olleolleolle]

After this, we can make more Gemfiles, to be able to run them next to each other, in the test platform matrix in Travis.

"You get an old ActiveSupport, you get a newer one."

All chosen via Gemfile versions, all appropriate to the versions we are testing.

[olleolleolle]

In travis.yml, we can include an env variable BUNDLE_GEMFILE=gemfiles/Gemfile.activesupport-4 for the build targets that need it.

And then, get rid of the weird RUBY_VERSION > '2.3' thing in the gemspec.

(Update: This turned out to be almost right. Below, we mention the gemfile Travis directive.)

[olleolleolle]

I could push on, in that direction, in this PR, to see if the changes bear out the promise.

Or, we could try taking it a step at a time.

[michaelklishin]

Please take your idea as far as you feel necessary.

[olleolleolle]

@michaelklishin Here's what the overview looks like when using the gemfile directive in the Travis build matrix https://travis-ci.org/gocardless/hutch/builds/161750953

[olleolleolle]

@jensnockert Does this work around #244?

[olleolleolle]

(Squashed to 1 commit: most learning Travis is best kept out of the long-term commit log.)

[michaelklishin]

This no longer merges cleanly.

[michaelklishin]

@olleolleolle thank you, I like this solution.

[olleolleolle]

@michaelklishin Rebased. Thanks for the encouragement.