Import Ruby 4.0.0 headers

Now that 4.0.0 stable is out, we no longer need these outdated headers.

I still left the 4.0.0-preview2 headers since dd-trace-rb CI is still,
as of this writing, using them, but once we update it those should be
cleaned up as well.

Why gem version 3.5 instead of
[4.0.0](https://rubygems.org/gems/debase-ruby_core_source/versions) like
upstream does?

So the reason upstream moved to 4.0.0 is to match the Ruby version;
e.g. before they shipped 4.0.0.preview2 and before that 3.4.1.

But I think this numbering format does not make sense for us.
Specifically, dd-trace-rb pulls in this gem in a format such as

```ruby
  spec.add_dependency 'datadog-ruby_core_source', '~> 3.4', '>= 3.4.2'
```

and thus regardless of you being on Ruby 2.5 or 4.0, you'll get the
latest version of this gem.

Coupling with upstream numbers is awkward because:
* For preview Rubies, a release like "4.0.0.preview2" doesn't get
  picked up by bundler automatically, so we'd add manual toil to
  customers that want to test preview releases
* We don't ship headers for every Ruby version. So what happens
  if we find out we need to add headers for Ruby 2.7.3 specifically?
  What release number do we use? 4.0.1? 4.0.0.2.7.3?
  Do we do a "patch release" from an older branch? But then how
  do we make sure the patch release gets picked up over a 4.0.0
  release that has a bigger number but does not yet have the 2.7.3
  headers?

So for the time being I propose we do the following:
* Decouple from upstream/ruby version schemes
* Bump the minor version whenever we release support for a newer
  Ruby. That is, for Ruby 4.0 we'll bump to 3.5.0, for 4.1 it
  will be 3.6.0, etc

In the end, I belive this is a two-way door decision -- e.g. nothing's
stopping us from changing our minds, and e.g. going back to match
upstream or other schemas in the future.

[PROF-13303] Remove 3.5.0-preview1 and 4.0.0-preview3 headers and bump gem version to 3.5.0