Stop running TravisCI against jRuby for now

I am starting to find it difficult to argue in favor of having jruby in
the list of TravisCI rubies.

It adds a bit of extra cost in maintenance and time spent waiting build to finish,
without feeling we're getting a lot out of it. Thus, the feeling is that it has low ROI.

Reasons behind my feeling of not "getting a lot out of it" includes:

- Almost never coming across a situation in which I thought to myself
"Hey, with this change we're making the gem incompatible with jRuby" because most
of the failures on jRuby builds where either heisenbugs and/or rvm installation
problems with jRuby, at least in my experience

- Usage share seems to be very very low, even compared to unmaintaned
MRI version, according to some sources, e.g.
https://semaphoreci.com/blog/2017/11/08/ruby-versions-used-in-commercial-projects-in-2017.html

.travis.yml

@@ -6,17 +6,9 @@ rvm:
   - 2.5.1
   - 2.4.4
   - 2.3.7
-  - jruby-9.1.16.0
 
 before_install:
-  # For jruby we need to stick with rubygems 2.7.4 until
-  # https://github.com/rubygems/rubygems/issues/2188
-  # is fixed and released.
-  #
-  # Without this workaround, for jruby builds, rubygems
-  # activates jruby stdlib minitest (v5.4.1) instead of the
-  # bundled version (v5.11.3).
-  - if [ "${TRAVIS_RUBY_VERSION:0:5}" = "jruby" ]; then gem update --system 2.7.4; else gem update --system; fi
+  - gem update --system
   - gem install bundler
 
 gemfile: