Proposal: Opt-in for additional meaningful exit-codes

In handover we have some tasks that have various failure scenarios; sometimes it would be most appropriate to bury a task, other times it could be re-queued, maybe with a delay.

Currently cmdstalk is quite opinionated as to how to handle job failures, this one size fits all policy makes for a fine default, but it would be nice if cmdstalk supported some opt-in behaviour to allow the job command a little more control of the release strategy.

Exit codes are already meaningful, in that a non-zero code will cause cmdstalk to act based on it's opinion to either bury or release the task with a delay. With that in mind I propose allow that default behaviour to be extended, via additional args to cmdstalk, along the lines of:

`cmdstalk -on-exit=255:BURY -on-exit=254:BACKOFF -on-exit=253:RELEASE ...`

This would override the default cmdstalk exit code handling, which is still a valid use-case for when it is not possible to control the exit codes of the job command, with a more targeted approach that allows the job command input into what happens next.

Possible release / verbs would look something like (_BURY_, _DELETE_, _RELEASE_, _BACKOFF_) with backoff representing an (exponential) backoff strategy similar to cmdstalk's current default mode of operation.