feat: support overriding the Prev time for a new job/entry

[dominicbarnes]

This PR adds a new capability to override the default "prev" time for a job during create, which has a number of useful applications.

First, it allows a schedule to be preserved across process restarts, keeping interval-based jobs from all being interrupted each time. The extra work needed to store/retrieve these timestamps is out of scope for this library, but this change allows that feature where it could not be done before. This could be considered a solution to #336.

Second, this can be a quick-and-dirty way to trigger jobs immediately, by simply choosing a "prev" time that is sufficiently far back in the past. It's a little janky, but there are tons of issues submitted about this very issue so I believe that utility would provide value. (this could be considered as an alternative fix for #436, #422, #406, #297, #396, #439, #356, #342, #336 and possibly others)

This is accomplished via a new ...EntryOption parameter for Cron.AddJob, Cron.AddFunc and Cron.Schedule, which isn't technically backwards compatible, as the function signature does change, but most code shouldn't need to be altered. This pattern mirrors New(...Option) Cron in structure, rather than trying to do something new. Currently, the only available option is WithPrev that sets Entry.Job before scheduling the job for the first time, but there could be room to add additional configurations if needed.

Additionally, Cron now considers the possibility that Entry.Prev may be nonzero, and will check that first, otherwise falling back on the current behavior of "now". In short, this is an opt-in feature, and should not change default behavior.