Add pilot hooks for job deletion

[bgentry]

Client.JobDelete, Client.JobDeleteMany, their Tx variants, and the job cleaner call the driver executor directly, so unlike cancels, retries, and completions, deletes never go through the pilot.

This adds an optional PilotJobDeleter interface with JobDelete, JobDeleteMany, and JobDeleteBefore (the job cleaner's batch delete). Like JobCancel and JobRetry, each hook receives the executor and driver params and performs the delete itself, so a pilot can substitute its own delete statement or run additional writes in the same transaction, using dbutil.WithTxV to reuse the caller's transaction when there is one. The job cleaner now receives the client's pilot through its config.

The interface is temporarily kept separate from Pilot, following the PilotJobRescuer pattern, so existing pilot implementations still compile. It isn't meant to stay optional: once supported implementations have adopted it, it gets embedded into Pilot and the executor fallbacks are removed, as the doc comment says. The client and cleaner use the hooks when the pilot implements them and fall back to the executor otherwise. StandardPilot implements them as plain executor calls, so default behavior is unchanged.

[brandur]

Thanks for trying to keep it compatible with the existing versions. The last two pilot changes were breaking, and it really reminded me as I was cutting releases that we need to stop doing that. If any pro user tries to upgrade after we release River but before we release River Pro, they'll get an error, and the full pro release still takes substantial time so that window is like an hour.