Update supported ruby versions

[jdleesmiller]

Many recent PRs had spurious CI failures due to end of life ruby versions in CI.

1. The (recent) failures were on gem update --system for old versions of ruby that are end-of-life.

   Ruby versions < 2.3 are now end of life: https://www.ruby-lang.org/en/downloads/branches and 2.3 is itself scheduled to be EOL on 31 Mar 2019.

2. fixed FrozenError caused by frozen-string-literal #390 added workarounds to not run gem update --system on those old versions. However, looking at git blame, it looks like gem update --system was added a long time ago in 2bd6ebe. In Travis: JRuby code coverage possible using the --debug flag, drop a failing JDK variant, use Rubinius rbx-3 #346, 43f01f4 mentions that it shouldn't be needed and removes it but then brings it back in cbdea2a (without comment, even though the previous CI run passed without it).

   I have tried removing it again, and it does not seem to be required now --- both JRuby and MRI builds seem OK with just using the default rubygems version. So, in this PR I have removed it.

3. I was instead going drop the EOL versions from travis, but in the gemspec we are still requiring ruby version >= 1.9.2, so I feel like we should continue testing on older versions until we bump that requirement.

   I found the discussion around Restore 1.9.3 and add 1.9.2 to .travis.yml #254 / Drop Ruby 1.9 support in changelog and gemspec #256, and it seems several users and contributors are of the opinion that dropping 1.9 from the test matrix, which was done because rubocop no longer supported 1.9, should have been a major version bump.

   My reading of the semver FAQ is that a major version bump is not required when a dependency is upgraded, but there are lengthy and interesting discussions about this, and I could be persuaded otherwise.

   For the moment, with gem update --system removed, the old ruby versions are not causing any problems, so I have left them in. If we want to upgrade rubocop again, which I think would be helpful for supporting frozen string literals (fixed FrozenError caused by frozen-string-literal #390 / Add test build with frozen strings #374), then we may need to drop them or remove rubocop as a dev dependency (it could e.g. go into the Gemfile in a group that would only be installed for some rubies, but this seems like a lot of complexity to support very old ruby versions).

4. I reverted Move jruby to allow failures matrix #375 - the underlying JRuby bug now seems to be fixed, so we don't need to ignore it.

5. The other source of spurious CI problems is coveralls: sometimes the coverage numbers drop even though no code has changed. I think we may need to enable parallel build support: http://docs.coveralls.io/parallel-build-webhook --- otherwise, I think there is a race on which build finishes last (usually one of the JRuby builds). I'm not sure about this, but I would like to try it out.

[jdleesmiller]

Since this is internal-only, I'm going to go ahead and merge it.