Not supporting partial completions for send, write, read makes
a lot of code paths way simpler, removes Futures from the globalIo and
allows more inheritance.

I don't think partial completion support is worth the hassle.
Partial completions cancel all dependent requests. Resubmitting some
in the chain breaks the semantic.

The global completer does not need to handle requests in its own io_uring.
We don't need templates for submit because submit works only from within
the Runtime. This allows submit to be virtual and be overridden by
Futures which issue a syscall before they submit them selves to the io_uring.

This and the absence of partial completions save a lot of conditions on
the fast path.

https://github.com/axboe/liburing/issues/273
linux commit: 48aba79bcf6ea05148dc82ad9c40713960b00396

This reverts commit a2241b6e.

Set errno only when using the POSIX like IO functions.
Future::wait will return either an negative error code or a positive result

AlarmFutures implemented IOURING_OP_TIMEOUT requests,
TimeoutWrappers are IOURING_OP_LINK_TIMEOUT requests and add the
wrapped Future as its dependency to link the timeout with it.

Introduce specialized Future subclasses API to the IO subsystem.
For each io::OPERATION request there exists a Class named <Operation>Future
(e.g. AcceptFuture(...), SendFuture(...)) with a constructor matching
the definitions of the known POSIX functions (e.g. accept(2), send(2)).

Using Futures objects instead of the the POSIX like interface provided
by io.hpp gives more Flexibility to the memory management as well
as the possibility to link IO requests.
Futures can be linked by declaring one the dependency of another.
A Future is only signaled if all IO requests it depends on are completed.

Example:

WriteFuture wf(fd, str, str_len, 0);
ReadFuture rf(fd, buf, buf_len, 0);
rf.addDependency(wf);
rf.submitAndWait();

Submitting a Future will also submit all its dependencies to the IO
subsystem.
Manually submitting a Future B which is the dependency of another Future A
before Future A is undefined behavior.

If an IO operation in a chain fails all dependent IO operations will
be completed with -ECANCELED.

Declare the single Future constructor as protected so a user can not
instantiate a plain Future object.

In order to use IORING_SETUP_SQPOLL all used file descriptors must
be registered with io_uring_register(2) syscall.
This needs a fixed array containing all file descriptor known by the
IoContext.
Because Futures and therefore the underlying file descriptor can
migrate between the worker and the global IoContext sophisticated
synchronization, tracking and registering of file descriptors would
be needed.

* use CamelCase to be more in line with the rest of the code base
* futures are now always submitted to a specific IoContext
* this moves all io_uring related code into the IoContext
* add new static IoContext functions to obtain IoContext objects

All output operations default to fully completions because the
User knows exactly how much should be written and don't care about partial
completions.

On the other hand input operations may not know how much data can be read
and returning early gives the possibility to process the retrieved data while
requesting more.

The global IoContext handels both Futures and completion events on different
IoContexts but reapCompletions only knows about Futures.

Futures completed by the globalCompleter thread are resubmitted if
if needed into the new global IoContext of the Runtime handled by the
globalCompleter.

Additional Changes:

* use two meson options io_uring_worker_entries and io_uring_global_entries
  to configure the amount of entries in the io_urings.
* Initialize all worker IoContexts and submit their eventfds to the globalIo
  before starting the globalCompleter in order to make synchronizing the SQ of the
  globalIo unnecessary
* delete all allocated IoContexts
* don't use a static IoContext member variable to access the Runtime's
  globalIo. Store the global IoContext in the runtime object.
* Commit each sqe immediately to the io_uring to prevent full SQs.
  This and the fact that the kernel consumes committed sqes emptying the SQ
  make busy loops around io_uring_get_sqe unnecessary.
* handle bool and "raw" meson options differently to prevent
  comparison of different types

Future::submit<ANYWHERE> and Future::submit<EMPER> can be executed
in parallel by the globalCompleter and.
To prevent possible data races of the io_urings SQ a new mutex
is introduced.
This new sq_mutex must be unlocked before calling reapCompletions() because
reapCompletions() may call Future::submit on not fully completed Futures
and thus causing a deadlock.

std::thread throws exceptions during exit.