I've tried two approaches to implement the Component Model for Ruby.
The first one is the *binary-editing* approach and the second one is
*extension-library* approach.

The basic idea of binary-editing* is to inject import/export sections
into a preview1 compatible .wasm binary and turn it into a Component by
`wasm-tool component new` command.

The approach was good for binary reusability. The binary before
injection can be used as a standalone WASI preview1 binary. Therefore
user can use a pre-built .wasm binary and just inject the import/export
sections to turn it into a Component.

However, considering the future dynamic linking support, the approach
introduces a bunch of complexity. In the dynamic linking era, an
extension library will be able to provide a WIT interface and a Ruby
core interpreter should not import or export anything except for WASI.
The binary editing approach needs to edit the Ruby core interpreter
binary every time when WIT world changes, so the build process would
be different from the one of dynamically linked extension library.

I decided to go to the extension library approach for mainainability.

The static linking build is just for a compatibility with the existing
Wasm runtimes, so I don't want to pay much effort for maintining it. The
extention library approach uses almost the same build process for static
linking and dynamic linking, so it's easier to maintain and we can focus
on the dynamic linking support.

The latest master broke the build. This commit pins the version to the
last known working commit.

Since there is no guarantee that the host system and the builder
container use the same Ruby ABI

…stall it

This package is alread tested by each ruby-version-specific package

to control cache key in rake

to use Bundler in rbwasm command