Split gem into Ruby and extension parts

未指定文件或测试。首先跟踪当前的 prism gem 打包方式和原生扩展构建，然后评估提议的 prism 和 prism-ext 构件以及 JRuby 的 WASM 路径；完成的标准是已实现拆分和平台行为，并且 JRuby prism 包排除原生库。

I would like to split the current Prism gem into two pieces: "prism" which contains the Ruby parts of the library, and "prism-ext" which contains the native extension and native library. This makes most sense for JRuby, but it would be simpler if done as a general move.

This is less of an issue and more of an idea that would make our lives easier in the JRuby world.

For JRuby users, the dependency on a native library is usually problematic. A large percentage of JRuby users (perhaps a majority) deploy JRuby into environments where there's no C build tools and frequently no allowances for random native libraries on the filesystem. Some of these deployments are all-in-one bundles that don't even unpack files to the filesystem. In such cases, the native library can't be built or loaded.

The most sensible option for the prism gem for JRuby would be that it ships only what can be run without native libraries; specifically this would mean prism would ship the WASM version of Prism so it can be embedded and bundled in all the ways JRuby users depend upon.

Users could opt-into the faster native Prism build by installing prism-ext or prism-library, which would build the dynamic library and make it available to the prism library. We would only ship prism as part of JRuby releases, since we need our distribution to always work across platforms.

The native-extension implementations would continue to just use the ext or the dynamic library as today.

The artifacts would look something like this:

• prism gem includes only the Ruby parts of the library and can be patched and versioned independently of the native code.
• prism-ext would work like the current prism gem does, building and installing either the CRuby extension or the dynamic library.
• The normal non-platform-specific version of the prism gem would depend upon prism-ext.
• The java platform version of the prism gem (for JRuby) would ship only the Ruby parts and the WASM library. Users can opt into the native version by installing prism-ext.

Alternatively, these changes would only apply to JRuby, and prism-ext would only be for JRuby users. Either way, the main prism gem for JRuby will need to exclude the native library.

I can think of other benefits to separating the extension into its own gem:

• CRuby users would be able to update just the Ruby part of Prism while still using the built-in native extension. This might make some bug fixes easier to distribute.
• If TruffleRuby in the future chooses to run Prism in a different form such as with Chicory or TruffleWasm, it would be a natural progression of this split.
• Doing the split uniformly (rather than just for JRuby) will keep the differences minimal. CRuby users would just get an additional extension dependency.