Build the Ruby layer for both x86_64 and arm64

[wpessers]

Fixes #2340.

The Ruby layer was built on x86_64 only, so its native gems (google-protobuf, bigdecimal) crashed on arm64.

What changes

• ruby/src/otel/Dockerfile now builds the gems for Ruby 3.3 and 3.4 on both linux/amd64 and linux/arm64 using the aws sam images, in four parallel stages. A final stage merges both architecture trees into one ruby/gems/<X.Y.0> and zips. RubyGems only activates specs whose platform matches the running machine, so both architectures' gems can live side by side.
• ruby/src/otel/install-gems.sh installs with the lockfile frozen and sets install_extension_in_lib: false, so compiled extensions exist only under extensions/<arch>-linux/ and never in the arch-agnostic gems/<name>/lib/. The build fails if any path differs between the two architecture trees, guarding against future clashes.
• The build action sets up QEMU for the arm64 stages and reads the SDK version from Gemfile.lock instead of running Ruby on the runner. The Ruby CI workflow now calls that action.
• The integration test asserts FunctionError is unset before parsing the payload, so an init crash surfaces as the real error.

The layer keeps its same name as today.

Perf Test Results

The layer no longer bundles rbenv's default gems, the gem download cache or generated docs, so it shrinks despite the added architecture:

	layer-ruby/0.13.0	this PR
zipped	38.7 MB	8.0 MB
unzipped	100 MB	16.5 MB

Verified locally with the Lambda emulator images (public.ecr.aws/lambda/ruby:3.3 and :3.4, amd64 and arm64) through AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler: all four combinations load the matching native libraries and start the SDK tracer provider.

[wpessers]

Superseded by #2665, same branch reopened from my fork so I can push follow-up commits (the EasyCLA ruleset blocks updates to branches on the upstream repo).