Callers of ProcessTaskManager.removeNextUnits() may get RuntimeException instead of OperationCanceledException

> While looking left and right at other silent AbortCompilation, I wondered if this guy should be improved, too: org.eclipse.jdt.internal.compiler.ProcessTaskManager.removeNextUnits() throws AbortCompilation like this:
>
> ```java
> } catch (InterruptedException interrupt) {
> throw new AbortCompilation(true/* silent */, new RuntimeException(interrupt));
> }
> ```
>
> This looks similar to the Parser use case, doesn't it? Could we think of a situation where this `new RuntimeException(interrupt)` could be useful? Or should we change this to `null` like in the Parser case? I see you already had a discussion concerning this very line in [#2948 (comment)](https://github.com/eclipse-jdt/eclipse.jdt.core/pull/2948#discussion_r1763140931) 😄

This opens another can of worms.
If I see it right, the AbortCompilation from that code is re-thrown here:

https://github.com/eclipse-jdt/eclipse.jdt.core/blob/b52cd52c0720bad9e39c50505c0c8f44d01e0f9f/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/Compiler.java#L491-L495

immediately handled here in same method:

https://github.com/eclipse-jdt/eclipse.jdt.core/blob/b52cd52c0720bad9e39c50505c0c8f44d01e0f9f/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/Compiler.java#L527-L529

and the wrapped `RuntimeException` is then re-thrown here:

https://github.com/eclipse-jdt/eclipse.jdt.core/blob/b52cd52c0720bad9e39c50505c0c8f44d01e0f9f/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/Compiler.java#L624-L633

... and then it looks like no one handles this exception properly, we have lot of callers here:

_Originally posted by @iloveeclipse in https://github.com/eclipse-jdt/eclipse.jdt.core/issues/4808#issuecomment-3822862539_