more consistent job canceling

[soxofaan]

Split off discussion from #436 (comment):

canceling a job with DELETE /jobs/{job_id}/results can have different outcomes in the current job status transition diagram:

• a job in state "queued" is moved back to "created"
• a job in status "running" is moved to "canceled"

problem (from #436 (comment)):

there is an arrow from "queued" to "created" with DELETE /jobs/{job_id}/results, but that same action also causes the transition from "running" to "canceled". So with same user action you you can end up in different state depending on what current state is (queued or running). The problem is that the transition from "queued" to "running" is under control of the backend, the user has poor insights here, they can at most poll for the current status and hope they don't run in race conditions. I would always go to "canceled" from DELETE /jobs/{job_id}/results to keep things more predictable