The inaccuracy is small, but it becomes visible when operating
within tight margins of the `sample_time`, like for example, when
working with a simulated clock in a test environment.

Specifically, `dt` cannot be exactly zero because it is used as
a divider. When it would be zero, it is set to a very small,
conventional value instead, that I've renamed MIN_DT for clarity.

When `dt == MIN_DT` it is really representing the case when it
would be zero. Not taking that value into consideration when
comparing the elapsed time since last computation does effectively
increase `sample_time` by `MIN_DT`. It is not a lot, but it is not
accurate either.

By correcting the comparison, very precise use of `sample_time`
becomes possible. One concrete use case is using simulated time
for testing.

Unless I'm misunderstanding something, the time necessary
for the system to converge should be stable, for any given
configuration of the PID and a given runtime environment.

I notice that the values 120s and 12s are close enough that
120 might have been a typo? Either way, my testing suggests
that 10s is sufficient for the system to converge on my machine.

However, the reliance on wall time for these tests means that
how fast the code is being executed does affect that value.
Before we fix that, I think that the 20% margin provided by
the existing value of 12s is reasonnable.

On my machine, this change reduces the overall time to run
the tests suite by a factor of five (from ~2m14 to ~26s).

This has a few advantages:

- Since time is frozen unless explicit resets or ticks happen,
  how long the test code takes to execute does not affect the
  test results. Specifically, this means that the `sample_time`
  can be matched precisely, and that makes for tests that are
  easier to reason about.

- Since time is controlled, it can flow at any speed we want.
  Two consecutive calls to `stime.tick()` will make two seconds
  pass as fast as your machine can execute the two statements.

The first advantage makes this test suite deterministic (because
the PID configuration is stable in convergence tests).

The second speeds up the overall execution of the test suite
by a factor of a hundred on my machine (from ~26s to ~200ms).

The `dt` option was added when `time_fn` was not available to
initialize PID instances.

Now that `time_fn` allows the time function to be injected as a
dependency, the `dt` option is redundant. It could be kept around
for backward compatibility, but I'd personally remove it because
IMHO the simpler the code the better.