[PROF-9044] Handle timing hiccups

[AlexJF]

What does this PR do?
Introduce a mechanism so that point-in-time hiccups in timing information cannot effectively lead to disabling of the sampler for whole minutes.

Motivation:
VM suspension, system overload and other noise may occasionally lead to timing hiccups where time where the application was suspended is misattributed to time spent sampling (e.g. VM suspension occurs in between calls to should_sample and after_sample).

This (hopefully) rare occurrence can skew our sampling statistics so much that the sampler would be effectively disabled for whole minutes. We want to limit this impact and try to have the sampler ignore sampling times that are deemed too big (our reference target is that, if forced to sample, we want to sample at least 1 event per second).

Additional Notes:
This PR tells a story:

1. We start by adding a test describing a scenario where due to some weird circumstance (e.g. suspension), the sampling time for a single event is reported as being 1000 seconds. With existing code the test fails with:

   1) Datadog::Profiling::Collectors::DiscreteDynamicSampler a weird hiccup shouldn't be able to disable sampling for whole minutes
    Failure/Error: expect(stats[:num_samples]).to be >= 60
    
      expected: >= 60
           got:    0
    # ./spec/datadog/profiling/collectors/discrete_dynamic_sampler_spec.rb:324:in `block (2 levels) in <top (required)>'
    # ./spec/spec_helper.rb:230:in `block (2 levels) in <top (required)>'
    # ./spec/spec_helper.rb:115:in `block (2 levels) in <top (required)>'
   

2. We then introduce a mechanism that limits the maximum amount of sampling time we're willing to consider. This maximum amount is chosen so as to represent a practical minimum sampling rate of 1 sample per adjustment window (ergo 1 sample per second). With this change the test passes:

     a weird hiccup shouldn't be able to disable sampling for whole minutes
   
    Finished in 0.08911 seconds (files took 1.03 seconds to load)
    1 example, 0 failures
   

How to test the change?

For Datadog employees:

• If this PR touches code that signs or publishes builds or packages, or handles
  credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
• This PR doesn't touch any of that.

Unsure? Have a question? Request a review!

[ivoanjo]

👍 LGTM

The macOS CI failures are unrelated -- #3444 .

[ivoanjo]

👍 LGTM