**What does this PR do?**

This PR adds the `ruby-4.0.gemfile` file that's needed for running
`bundle install` on Ruby 4.0.0-preview2.

The contents of this file being added are copy/pasted from
`ruby-4.0.gemfile` with no changes.

I did not add or change anything on purpose: This is a very minimal
part of the Ruby 4 CI support being prepared in
#5084 but
unlocks local development with Ruby 4.0. I suggest we keep
adjustments/cleanups/etc for that later PR where we officially add Ruby
4.0 to our CI.

**Motivation:**

Without this file it's impossible to do local development on
Ruby 4.0.0-preview2.

It also came up in
<DataDog/datadog-ruby_core_source#19>:
we want to check if the profiler extension compiles on Ruby 4.0 and
we're not able without this file.

With this PR we can run `bundle install` and start running tests
and tackling what's missing.

**Additional Notes:**

N/A

**How to test the change?**

Validate that it's possible to run `bundle install` on Ruby 4.0.

**What does this PR do?**

This PR temporarily disables the "Ruby 4.0 corruption" test that's
blocking us from releasing the gem as per
<https://github.com/DataDog/datadog-ruby_core_source/actions/runs/20057267656/job/57525327190>.

**Motivation:**

Release latest version of the gem, including Ruby 4.0.0-beta2 support.

**Additional Notes:**

The issue in question is caused by dd-trace-rb currently pinning Ruby
4.0 to a specific hash
(in https://github.com/DataDog/dd-trace-rb/blob/48b4d79d6d043271dc760277ddc820f5343f335c/ruby-4.0.gemfile#L81).

This interacts incorrectly with the "corruption" test, making it use
the wrong version of the gem:

(This is the output from the `bundle info` right before the test runs
showing the wrong version being used for the "Add
datadog-ruby_core_source" step, from
<https://github.com/DataDog/datadog-ruby_core_source/actions/runs/20057267656/job/57525327190>)

```
  * datadog-ruby_core_source (3.4.1 7b95302)
	Summary: Provide Ruby core source files
	Homepage: https://github.com/DataDog/datadog-ruby_core_source
	Path: /usr/local/bundle/bundler/gems/datadog-ruby_core_source-7b95302a593c
	Reverse Dependencies:
		datadog (2.23.0) depends on datadog-ruby_core_source (~> 3.4, >= 3.4.1)
```

The expected correct output can be seen in
<https://github.com/DataDog/datadog-ruby_core_source/actions/runs/20057267656/job/57525327215>:

```
  * datadog-ruby_core_source (3.4.2)
	Summary: Provide Ruby core source files
	Homepage: https://github.com/DataDog/datadog-ruby_core_source
	Path: /__w/datadog-ruby_core_source/datadog-ruby_core_source/datadog-ruby_core_source
	Reverse Dependencies:
		datadog (2.23.0) depends on datadog-ruby_core_source (~> 3.4, >= 3.4.1)
```

This messup makes CI fail even though everything is fine.

This is a loop: dd-trace-rb requires the pinning BECAUSE we haven't
released this gem yet.

So to break the loop, let's:
1. omit this test temporarily
2. then we can release this gem
3. then we can undo the dd-trace-rb pinning
4. then we can re-enable the test

This PR is step 1. I'll take care of all 4 ;)

P.s.: Why didn't we see this before? That's because the dd-trace-rb
pinning was not there when we initially added the 4.0.0-preview2
headers in #19. Then the pinning was added on the dd-trace-rb side and
it silently created this problem for datadog-ruby_core_source CI.

**How to test the change?**

CI should be green after this change.