Right now job futures are required to be `Send`. However this
requirement is actually unnecessary as the job futures are polled in
the UI loop and not send to another thread with `tokio::spawn`.

The reason this requirement was likely added is so that some utilities
from the `futures` crated (`BoxedFuture`, `boxed()`) could be used.
However these utilities are just trivial convenience functions that
are easily replaced and only contain the `Send` bound for convenience
as most futures are polled with `await` and potentially send across
threads.

The bound was removed so that UI components could be returned as a
future instead of being build synchronously on the main thread.

Currently, there are two ways to deal with a blocking computation needed
to display a UI component: Performing the computation directly in the
UI loop while responding to user feedback (so usually in `commands.rs`).
Or creating a job that polls an async future and displays the UI
component when ready. Both approaches are not a good fit for this
use case. Blocking the UI thread will freeze the editor if the
computation takes longer than expected. Meanwhile, asynchronous jobs
have the opposite problem: When the future takes a long time to
complete there is no direct response. The user may attempt to
repeat the same command or keep editing. At a later point the UI
component will appear and interrupt the workflow. Furthermore, if the
computation consumes lots of resources it will continue doing so in the
background with no way to terminate it.

To address this use case a new job is introduced to the editor: A
`BlockingJob`. A blocking job acts mostly like a normal job: It is an
asynchronous future that is polled in the UI loop yielding a callback.

While a blocking job is running, the editor is softlocked.
The core UI loop is not blocked, and therefore the editor will continue
to respond to external events like signals, keyboard input and screen
size changes. However, all input by the user is ignored, and all UI
elements are dimmed. The user is prompted to press `c-c` to abort the
running job which will cancel the blocking job through a `Cancelation`.

The `Cancelation` can be efficiently checked synchronously
(compiles down to an atomic read) while also acting as a future.
It is up to the caller to ensure that the constructed future responds
quickly to being canceled to avoid any UI delay.