This isn't great since we're allowing a null field and checking
for null, but the logic surrounding this has been designed to
lazily create the channel or stream in question. This is likely
due to the use of URLResource and its siblings as generic path/URI
mungers that can clean up and canonicalize/abosolutize even paths
that do not exist. Rather than attempt to isolate that behavior
(which might be a lot more work), I've opted to mimic FileResource
in raising an error along the lazy path when it's clear we don't
have a resource in hand to open.

This fixes jruby#6219.

Because all modules will report isOpen => true when called from
the unnamed module, we need a different way of accessing them.
This logic makes two changes:

* Use Lookup to acquire a method handle rather than using the
  reflected object. This allows to be sure we now have a fully
  accessible mechanism for accessing the related field or method,
  without triggering any warnings. Lookup.unreflect* will raise
  an exception if the reflected object is not already accessible,
  rather than a warning we cannot detect.
* Use addOpens to attempt to *really* make the pseudo-open
  packages be open. This allows us to proceed to setAccessible
  knowing the package has moved from "kinda-sorta-open" to really
  open.

The fallbacks here occur in the following cases:

* If we cannot acquire a reference to a non-standard JDK class,
  like those in sun.nio.ch. This should not ever fail; reflecting
  against these classes is always permitted.
* If we cannot acquire the method or field in question because it
  is not there. Again this should not fail under normal
  circumstances.
* If we cannot unreflect a handle and cannot addOpens for the
  package in question.

This is a partial fix for jruby#6103. The issue there is that in 9.2.10
we updated to a version of RubyGems that no longer supports the
--no-rdoc and --no-ri flags. Normally the build here would run
with 9.2.7.0, which does support those flags, but when running a
SNAPSHOT build we use the version of JRuby that we're building.
If that version is >= 9.2.10.0 it will fail because the --no-rdoc
flag is not recognized.

We could fix it by enabling rdoc and bypassing the relevant logic
in the InstallMojo from gem-maven-plugin, but we don't really want
to install rdoc and ri for the bootstrap gems.

Instead, I am forcing this to always use 9.2.7.0 until we can get
the plugin updated to a newer JRuby and fix the flags
appropriately.

This allows a non-SNAPSHOT bootstrap to almost work; it then fails
with the issue in jruby#6174. I will commit a separate workaround for
that.

Works around jruby#6103.