Use a polling mechanism instead of a look-forward loop

[sheerlox]

Refactor to poll and fire when condition is true.

Simplifies code a great deal and avoids all the issues which have repetitively been seen in attempts to determine the next running time.

This includes all the issues which were seen with using loops to look forward in time.

Originally posted by @mryellow in #962

[sheerlox]

@mryellow hmm. Yes, on one hand, that would simplify the code and prevent more issues with the loop mechanism in the future (this one is the last one "from the old days", so the mechanism should be pretty stable once it's fixed).

On the other hand, that would probably raise new types of issues we have never seen.

For example, what would happen if the event loop is blocked for a second when the polling mechanism would have triggered a tick? How could we detect that an execution has been missed in those cases to catch back?

The performance implications are also interesting. The polling mechanism would have to run every second (probably more frequently to mitigate the previous paragraph's issue), but since we'd only be checking for the current time it would be way less resource-intensive.

We'd also need a mechanism to prevent jobs from being run twice in a single second, which currently isn't an issue.

These are just the first observations that came to mind. A refactor this deep would have a lot of impacts we would have to take into consideration.

Given how widely used this library is in the ecosystem, we can't take this kind of refactoring lightly, and since we've almost fixed all bugs related to the look-forward logic, I don't think it would be a risk worth taking (nor time well spent).

But this is interesting nonetheless, I'm happy to entertain the discussion!