Runner\get_next_job() should explicitely state an order

[dd32]

Currently get_next_job() does two things wrong IMHO:

• Doesn't specify a LIMIT 1 - which while implied by the fetchObject() call, still causes all waiting jobs to be returned to the client buffer
• Doesn't specify a ORDER BY - What this causes is that when jobs get backlogged, jobs run in an order as determined by their id rather than by their order of nextrun, which can result in some unexpected behaviours in cron jobs (if a specific time, say an hour after another job was specified, and can cause some unexpected behaviours in cron jobs)

The ORDER BY shouldn't be an issue, except when backlogged by something such as #37

[rmccue]

I feel like I chose not to include the LIMIT for some reason, but cannot remember why. In any case, 👍 on changing it.

Ditto 👍 on adding ORDER BY