Better build orchestration

The underlying build system of rbwasm build is quite messy.

1. Each build step has to have its ad-hoc up-to-date check like followings:
   https://github.com/ruby/ruby.wasm/blob/a5d06a01873130fda0f07f4401a3b018c6f1d753/lib/ruby_wasm/build/product/baseruby.rb#L26 https://github.com/ruby/ruby.wasm/blob/a5d06a01873130fda0f07f4401a3b018c6f1d753/lib/ruby_wasm/build/product/crossruby.rb#L171
2. Uses of build product and cache key computation are placed far, so we often forget to update the cache key and get a wrong cache restored.
   https://github.com/ruby/ruby.wasm/blob/a5d06a01873130fda0f07f4401a3b018c6f1d753/lib/ruby_wasm/build.rb#L78
3. The current cache mechanism cannot restore two or more artifacts produced within a single rake task job. This usually happens for PIC & non-PIC builds invoked by rake npm:ruby-head-wasm-wasi:build
4. Our cache mechanism does not allow partial cache-hit, so even if we change only crossruby source revision, we have to rebuild openssl from scratch.
5. Our cache mechanism is not sensitive to recipe changes. For instance, even if we change CFLAGS value, crossruby product will not be rebuilt.

Start by reading lib/ruby_wasm/build.rb and the product implementations in lib/ruby_wasm/build/product/baseruby.rb and crossruby.rb. Trace the rake npm:ruby-head-wasm-wasi:build entry point and its PIC and non-PIC artifacts. Done means the build cache handles multiple artifacts, partial hits, and changes to source revisions and recipes without restoring incorrect results.