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

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

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

std::thread throws exceptions during exit.

IO requests issued from fibers will be queued into the io_uring of
the worker's IoContext.
Before retrieving the next fiber to run in the DispatchLoop the
worker tries to reap all completions which occurred in its io_uring and
schedules the now runnable fibers.

To process IO completions on sleeping worker threads there exists
a global completer thread.
All worker io_urings register an eventfd which signals ready completions
and insert a read from this eventfd into a global io_uring.
The global completer thread waits for completions on the global io_uring,
which signal available completions on a worker's IoContext and tries to
reap the worker's completions and schedules all now runnable Fibers
on the AnywhereQueue.

The assumption of this design is that it reduces contention on the IO
subsystem and schedules fibers blocked on IO back into the workers
work-stealing queue and not into the global AnywhereQueue.

Fix debug recording of not submitted futures.

Split up and move all IO related code into emper/io.
The intended way to use emper's IO subsystem is by including either
the io.hpp for C++ or the emper.h header for C code.

All components of the IO subsystem are now encapsulated in emper::io::IoContext.
An IoContext consists of a io_uring, an Actor to submit requests to the io_uring,
a thread that collects cqes from the io_uring and unblocks waiting fibers as
well as some debug and statistic variables.

In theory there could exist more than on IoContext but the public IO
API defined in io.hpp will use the one created and set by the runtime.

When a runtime is instantiated it will create a new IoContext which will
schedule a SubmitActor and start the completion thread.
This means the IoContext must be created after the Scheduler.