Enforce JRuby as the supported ruby for running Warbler itself

[chadlwilson]

Warbler currently implicitly half-supports being run under CRuby to package archives: the gem installs anywhere (platform = Gem::Platform::RUBY), and the packaging engine falls back from warbler_jar.jar to pure-Ruby rubyzip when JRUBY_VERSION is not defined. This was never made an explicit contract (see #324) and should be tightened to JRuby-only, because packaging
under CRuby is quietly broken by design:

• Wrong-platform gem resolution: Bundler/RubyGems resolve gems for the building ruby. Under CRuby that means ruby-platform gems (e.g. native extension nokogiri/psych instead of their -java variants) get packed into an archive that will only ever run on JRuby - assembling fine at build time and failing at boot.
• Latent crashes: e.g. Warbler::Jar#find_single_gem_files references bare JRUBY_VERSION (jar.rb:221) in the default-gem branch - NameError on CRuby.
• JRuby-only features: the compiled feature shells out to jrubyc; symlink handling is JRuby-only (jar.rb:313).
• Zero coverage: the spec suite only runs under JRuby; MRI behaviour is whatever has not rotted since someone last tried it.

Proposed

• Fail fast (or at minimum warn loudly) when RUBY_ENGINE != 'jruby', pointing at JRuby as the supported build ruby
• Document JRuby-only usage in the README
• Remove the now-unreachable MRI accommodations: the rubyzip fallback path (ZipSupport vs warbler_jar.jar conditional), defined?(JRUBY_VERSION) guards, and the MRI symlink warning
• Consider spec.platform = 'java' for the gem itself so installation is the enforcement point

Refs #324: the request to properly support MRI packaging - this issue resolves that question in the opposite direction, which the wrong-platform gem resolution problem makes the only sound one.
Refs #408: warning or preventing JRuby version skew - an even worse problem likely to generate jars/wars broken on a given JRuby version.

---

Summarised with Claude assistance.