Mark free blocks in pooled carriers as unused

This lets the OS reclaim the physical memory associated with these
blocks which reduces the impact of long-lived awkward allocations.
A small allocated block will still keep a huge carrier alive, but
the unused part of the carrier will now be available to the OS.

Co-authored-by: Dmytro Lytovchenko <dmytro.lytovchenko@erlang-solutions.com>

At start of the VM a poll-set that the schedulers
will check is created where fds that have triggered
many (at the moment, many means 10) times without
being deselected inbetween. In this scheduler specific
poll-set fds do not use ONESHOT, which means that the
number of syscalls goes down dramatically for such fds.

This pollset is introduced in order to handle fds that
are used by the erlang distribution and that never
change their state from {active, true}.

This pollset only handles ready_input events,
ready_output is still handled by the poll threads.

During overload, polling the scheduler poll-set is done
on a 10ms timer.

The poll thread does a lot of waking up and then going
back to sleep. A large part of the waking up is managing
thread progress and a large part of that was using thread
specific data to get the thread progress data pointer.
With this refactor the tpd is passed to each of the functions
which greatly decreases the number of ethr_get_tsd calls
which in turn halves the CPU usage of the poller thread in
certain scenarios.

This bug was introduced in 988f5f5e8061ce2. The aux_thread
needs to be poked as it is the thread that handles all
break actions.

The standard search order does not include the directory that the
loaded DLL resides in, requiring dirty $PATH hacks to get things
working, which is not an option now that os:putenv/2 is divorced
from the OS environment.

putenv(3) and friends aren't thread-safe regardless of how you slice
it; a global lock around all environment operations (like before)
keeps things safe as far as our own operations go, but we have
absolutely no control over what libc or a library dragged in by a
driver/NIF does -- they're free to call getenv(3) or putenv(3)
without honoring our lock.

This commit solves this by setting up an "emulated" environment which
can't be touched without going through our interfaces. Third-party
libraries can still shoot themselves in the foot but benign uses of
os:putenv/2 will no longer risk crashing the emulator.