This reverts commit 3b5842c9c41a441280100045ef62bb8a0fe7200f.

The intent of the original commit was to begin enabling asynchronous
alloation actions (calls attached to JIT'd memory initialization and
deinitialization). The asynchronous allocation actions scheme was
fleshed-out in a development branch, but ran into an issue: Functions
implementing actions are allowed to live in JIT'd code (e.g. in the ORC
runtime), but we can't genally rely on tail-call elimination kicking in.
This resulting in dealloc actions returning via stack frames that had
been deallocated, triggering segfaults.

It's possible that there are other approaches that would allow
asynchronous allocation actions to work, but they're not on the critical
path for JIT improvements so for now we'll just revert.

Part of ongoing work to make core ORC operations asynchronous.

This only affects the runner utilities, not the AllocationActions themselves.
The AllocationActions will be made asynchronous in a future patch.

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.

Fix 'use of undeclared identifier' build errors for shm_ functions on
z/OS by implementing the functionality using shmget(), shmat(), and
shmdt(). Use the BLAKE3 hash to map the name of the shared memory to a
key.

---------

Co-authored-by: Kai Nacke <kai.peter.nacke@ibm.com>

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.

This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.

This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.

This reapplies 2cc64df0bd6a802eab592dbc282463c3e4a4281c, which was reverted in
5379c46d490640bfa80283e00240b6f1006092b4 due to bot failures.

The new patch contains fixes to ELFLinkGraphBuilder.h to better handle
non-SHT_ALLOC sections (these were being accidentally skipped in the previous
patch), and to skip SHT_NULL sections.

This reverts commit 2cc64df0bd6a802eab592dbc282463c3e4a4281c while I investigate
bot failures (e.g. https://lab.llvm.org/buildbot/#/builders/3/builds/23081).

The original MemDeallocPolicy had two options:
* Standard: allocated memory lives until deallocated or abandoned.
* Finalize: allocated memory lives until all finalize actions have been run,
            then is destroyed.

This patch introduces a new 'NoAlloc' option. NoAlloc indicates that the
section should be ignored by the JITLinkMemoryManager -- the memory manager
should allocate neither working memory nor executor address space to blocks in
NoAlloc sections. The NoAlloc option is intended to support metadata sections
(e.g. debug info) that we want to keep in the graph and have fixed up if
necessary, but don't want allocated or transmitted to the executor (or we want
that allocation and transmission to be managed manually by plugins).

Since NoAlloc blocks are ignored by the JITLinkMemoryManager they will not have
working memory allocated to them by default post-allocation. Clients wishing to
modify the content of a block in a NoAlloc section should call
`Block::getMutableMemory(LinkGraph&)` to get writable memory allocated on the
LinkGraph's allocator (this memory will exist for the lifetime of the graph).
If no client requests mutable memory prior to the fixup phase then the generic
link algorithm will do so when it encounters the first edge in any given block.

Addresses of blocks in NoAlloc sections are initialized by the LinkGraph
creator (a LinkGraphBuilder, if the graph is generated from an object file),
and should not be modified by the JITLinkMemoryManager. Plugins are responsible
for updating addresses if they add/remove content from these sections. The
meaning of addresses in NoAlloc-sections is backend/plugin defined, but for
fixup purposes they will be treated the same as addresses in Standard/Finalize
sections. References from Standard/Finalize sections to NoAlloc sections are
expected to be common (these represent metadata tracking executor addresses).
References from NoAlloc sections to Standard/Finalize sections are expected to
be rare/non-existent (they would represent JIT'd code / data tracking metadata
in the controller, which would be surprising). LinkGraphBuilders and specific
backends may impose additional constraints on edges between Standard/Finalize
and NoAlloc sections where required for correctness.

Differential Revision: https://reviews.llvm.org/D146183