…ofiler

**What does this PR do?**

This PR fixes a corner case issue with the allocation profiler: if too
many objects get allocated, we "clamp" the weight of every individual
sample (to avoid introducing bias) to a maximum value.

But we previously did not in any way represent the clamping on the
profile itself, which meant that the total number of allocations
reported by the profiler would be missing any object counts that
were clamped.

In practice, we don't expect this to happen very often, as we have
a high clamping value `MAX_ALLOC_WEIGHT = 65535` (it's in
`collectors_cpu_and_wall_time_worker.c`).

This PR then introduces an extra placeholder sample, when needed,
to represent allocations that went over the clamped value.

Thus the total amount of objects allocated reported by the profiler
now becomes accurate, even in the presence of clamping.

**Motivation:**

We're considering lowering the maximum clamping value, which would mean
it would be hit more often, and thus it's important to fix this issue
before we do that.

**Additional Notes:**

N/A

**How to test the change?**

I've added test coverage for this change. I also used the following
snippet to quickly experiment while I was developing this PR:

```ruby
Datadog::Profiling.wait_until_running
allocator = Thread.new { loop { BasicObject.new } }
sleep 10
allocator.kill; allocator.join
puts "Allocated #{GC.stat(:total_allocated_objects)} objects total"
```

…name

This was a great suggestion from the PR review.

…eap profiler

I missed it on my original commits, but the placeholder for skipped
samples broke the heap profiler, as it started failing with:

> W, [2024-07-08T15:41:27.128532 #366230]  WARN -- datadog: [datadog]
> CpuAndWallTimeWorker thread error. Cause: RuntimeError Ended a heap
> recording that was not started Location:
> missing-testcase.rb:2:in `new'
> W, [2024-07-08T15:41:27.128583 #366230]  WARN -- datadog: [datadog]
> Detected issue with profiler (worker component), stopping profiling.
> See previous log messages for details.

This is triggered by how our current heap profiler integrates with
the rest of the profiler: it expects to be called twice for each
allocation sample -- once before the stack is collected, and once
after.

The implementation of the placeholder for skipped samples correctly
did not call the heap profiler before the placeholder stack got
collected BUT we were still calling the heap profiler after.

This caused its internal consistency checks to fail.

The fix for this is to not call the heap profiler after the
placeholder sample. I chose to add a new argument to `record_sample`
which is not particularly pretty, but I guess until we come up with
a better way to have the heap profiler integrate with the rest of
the components, it'll do.