**What does this PR do?**

This PR adds the ability to override the folder used for reading the
headers from using an environment variable:
`DATADOG_RUBY_HEADERS_OVERRIDE`.

This way, when building the `datadog` gem, we can point directly
at any Ruby source tree and use the headers in it.

**Motivation:**

We have an existing similar mechanism in libdatadog
(https://github.com/DataDog/libdatadog/blob/91c0d493f5b62bde6c5f1971e7814f2478b63bf1/ruby/lib/libdatadog.rb#L24)
which comes in really handy when we want to quickly test out some
change without having to hack the gem or copying over files.

I was using it today to test against latest ruby-head, without
having to import those headers explicitly first.

**Additional Notes:**

N/A

**How to test the change?**

This can be easily tested by building the profiler (e.g. `bundle exec
rake clean compile`) in the dd-trace-rb repo.

Here's how it looks without this override on Ruby master:

```
**************************************************************************
No source for ruby-3.5.0 (revision a0fe0095ab2711ba54b29cdd2a5957f993cfc1de) provided with
datadog-ruby_core_source gem. Falling back to ruby-3.5.0-preview1.
**************************************************************************
Using datadog-ruby_core_source headers from datadog-ruby_core_source/lib/datadog/ruby_core_source/ruby-3.5.0-preview1
```

and with the override:

```
Using datadog-ruby_core_source headers from .rvm/src/ruby-head
```

…der-override

[PROF-11809] Allow overriding headers folder using env var

Fixes #17

Along the same lines as 852162a, this
commit imports the Ruby 4.0.0-preview2 headers into the gem.

** Motivation **

It's not possible to install this gem on 4.0.0-preview2 without these
headers. Falling back to 3.5.0-preview1 does not work, since there is an
ABI change in shape.h

** How to test the change? **

Adding these headers allowed me to install the gem on Ruby
4.0.0-preview2. I guess we'll eventually want dd-trace-rb CI to run
against Ruby 4.0.

Add Ruby 4.0.0-preview2 headers

**What does this PR do?**

This PR bumps the gem version to 3.4.2 in preparation for releasing
Ruby 4.0.0-preview2 support (added in #18).

It also updates the `test-compilation.yml` checks to run with Ruby 4.

**Motivation:**

Release a new version with support for 4.0.0-preview2.

**Additional Notes:**

**How to test the change?**

The CI check validates this change + I've tested it locally by
running `bundle exec rake package`, installing the result, and then
confirming the profiler successfully builds with it
(tested Ruby 3.4 and 4.0 manually).

[PROF-13115] Bump gem version to 3.4.2

**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.

[PROF-13115] Temporarily skip broken Ruby 4 test to unblock gem release