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.

Empieza leyendo lib/ruby_wasm/build.rb y las implementaciones de producto en lib/ruby_wasm/build/product/baseruby.rb y crossruby.rb. Sigue el punto de entrada rake npm:ruby-head-wasm-wasi:build y sus artefactos PIC y no PIC. Se considera terminado cuando la caché de compilación gestiona varios artefactos y aciertos parciales, así como cambios en las revisiones del código fuente y en las recetas, sin restaurar resultados incorrectos.