gitlab: don't interrupt "obsolete" running jobs

Making jobs interruptible usually makes little difference to reducing the workload / queue size of the runner, since it only applies in a pretty specific case: when a new push happens to the same repository and branch as the one job that is currently running. But when it happens, it often gives us the worst of both worlds: CPU time is spent anyway (maybe even 99% of the job) but we don't get a result from it.

I just saw a 34-minute-ETA job get interrupted after 25 minutes due to another push, the new job ran for 15 minutes and got interrupted again, with nothing else queued. This means those 40 minutes of work were completely wasted. If we already started running it, we might as well let it finish...

This reverts commit 36144a29. It seemed like a good idea at the time and I approved of it, but seeing it work in practice made me change my mind...

(AFAIK the real purpose of the interruptible feature in gitlab is to avoid the case where you push buggy code, notice before it gets auto-deployed to a server, push a fix, and the previous job continues to completion anyway and deploys the broken code. We may want to consider it for website deployment jobs in the future, but I don't see the point for C++ CI.)