Debounce: sliding mode

[freiondrej-lokalise]

First of all, thank you for implementing debouncing! Much appreciated. 🚀

We have a usecase which is not supported out of the box if I'm not mistaken - we have a refresh job that we want to have debounced, but differently from the current Fixed mode, it would be pushed N ms into the future every time the job tries to be scheduled. Let me illustrate with an example:

In the current Fixed mode, let's say we schedule a job A with 5s TTL and a 5s delay. Then, after 3 seconds, we try to schedule a new job B with the same debounceKey. It is ignored, so in 5s from the start, job A runs (because of the delay).

In the suggested Sliding mode, we schedule job A with 5s TTL and 5s delay. Then, after 3 seconds, we schedule a new job B with the same debounce key and the same 5s TTL and 5s delay. Job A is discarded before it ever runs, and job B runs 8s from the start (3s from the beginning + its 5s TTL).

(We could also think of this mode as "overriding" mode, as the last job is the one that ends up being executed.)

---

There's also another question, how to behave when the latest job is still running and a new one is scheduled with the same debounceKey.

Example to illustrate what I just mentioned (building up on the example from the previous section):

1. we schedule job A with 5s TTL and 5s delay. 3 seconds in, we schedule job B with the same debounceKey and the same 5s TTL and 5s delay. On the 8th
   second of the timeline, job B starts and it takes 10 seconds to process (so it ends on the 18th second in total). On the 12th second in total, job C is scheduled with the same debounce key and the same 5s TTL and 5s delay. Job C starts running on the 17th second in total, while job B is still active.

2. we schedule job A with 5s TTL and 5s delay. 3 seconds in, we schedule job B with the same debounceKey and the same 5s TTL and 5s delay. On the 8th
   second of the timeline, job B starts and it takes 10 seconds to process (so it ends on the 18th second in total). On the 12th second in total, job C is scheduled with the same debounce key and the same 5s TTL and 5s delay. We ignore job C, as job B is still running (pretty much like in Extended mode).

3. we schedule job A with 5s TTL and 5s delay. 3 seconds in, we schedule job B with the same debounceKey and the same 5s TTL and 5s delay. On the 8th
   second of the timeline, job B starts and it takes 10 seconds to process (so it ends on the 18th second in total). On the 12th second in total, job C is scheduled with the same debounce key and the same 5s TTL and 5s delay. We wait until job B finishes, then start the countdown, so job C starts running on 23rd second in total.

4. we schedule job A with 5s TTL and 5s delay. 3 seconds in, we schedule job B with the same debounceKey and the same 5s TTL and 5s delay. On the 8th
   second of the timeline, job B starts and it takes 10 seconds to process (so it ends on the 18th second in total). On the 12th second in total, job C is scheduled with the same debounce key and the same 5s TTL and 5s delay. The TTL/delay ends on the 17th second in total, but job B is still running. Job C waits until job B finishes, then runs immediately as its TTL/delay finished already, that means job C starts running on the 18th second in total.