Guard against invalid schedule loading

[taf2]

If a bad crontab is published to a schedule this will blow up and cause the process to become corrupted. This causes lots of schedules to be missed.

[meatballhat]

@taf2 Hello! Can you rebase against master, and please edit your commit message to remove the profanity? Thank you! 😸

[iloveitaly]

@taf2 friendly reminder on this PR!

[PatrickTulskie]

@taf2 hey just a heads up, I'm making moves to get through a bunch of the PR backlog for resque scheduler. This looks like a good candidate for 5.0.1. If you have a chance, can you rebase and push this up again and I'll get it live? If you're not or I don't hear back from you in the next week or so, I'll have my agent rebase and open a fresh PR with your change so you still get credit for the contribution.

This PR has a bunch of extra stuff in it too, so the only part that we would want to keep is the the check that stops a bad cron string from crashing the scheduler. If it's easier, maybe pull that fix into another PR and close this one.

[taf2]

Let me see - away from keyboard but might be able to shortly

[taf2]

Rebased onto current master and pushed as 23c5058. The PR now contains only the invalid-schedule guard, regression tests, and the corresponding RuboCop module-length adjustment; the unrelated changes and old commit messages have been removed.

Invalid cron strings are logged and skipped so the remaining schedules can still load. The regression tests cover both a malformed cron with options and loading a valid schedule after a malformed entry.

Validation: all 297 tests pass (627 assertions), and RuboCop passes. The new regression tests also fail against unmodified master, confirming they reproduce the issue.