7381558ef8b renamed the FinalizeRequest type to InitializeRequest. This commit
updates InitializeRequest variable names to follow suit ("FR"s become "IR"s).

This commit renames the "finalize" operation to "initialize", and
"deallocate" to "deinitialize".

The new names are chosen to better fit the point of view of the
ORC-runtime and executor-process: After memory is *reserved* it can be
*initialized* with some content, and *deinitialized* to return that
memory to the reserved region.

This seems more understandable to me than the original scheme, which
named these operations after the controller-side JITLinkMemoryManager
operations that they partially implemented. I.e.
SimpleNativeMemoryMap::finalize implemented the final step of
JITLinkMemoryManager::finalize, initializing the memory in the executor;
and SimpleNativeMemoryMap::deallocate implemented the final step of
JITLinkMemoryManager::deallocate, running dealloc actions and releasing
the finalized region.

The proper way to think of the relationship between these operations now
is that:

1. The final step of finalization is to initialize the memory in the
executor.

2. The final step of deallocation is to deinitialize the memory in the
executor.

In an ORC JIT it's common for multiple memory regions to be deallocated
at once, e.g. when a ResourceTracker covering multiple object files is
removed. This commit adds SimpleNativeMemoryMap::deallocateMultiple and
SimpleNativeMemoryMap::releaseMultiple APIs that can be used to reduce
the number of calls (and consequently IPC messages in cross-process
setups) in these cases.

Adding these operations will make it easier to write an
llvm::orc::MemoryMapper class that can use SimpleNativeMemoryMap as a
backend.

This commit aims to align SimpleNativeMemoryMap::FinalizeRequest::Segment with
llvm::orc::tpctypes::SegFinalizeRequest. This will simplify construction of a
new LLVM JITLinkMemoryManager that's capable of using SimpleNativeMemoryMap as
a backend.

This header was a placeholder in the initial project check-in, but is not used.
Time to remove it.

An orc-rt Session contains a JIT'd program, managing resources and
communicating with a remote JIT-controller instance (expected to be an
orc::ExecutionSession, though this is not required).

SimpleNativeMemoryMap is a memory allocation backend for use with ORC.
It can...

1. Reserve slabs of address space.
2. Finalize regions of memory within a reserved slab: copying content
into requested addresses, applying memory protections, running
finalization actions, and storing deallocation actions to be run by
deallocate.
3. Deallocate finalized memory regions: running deallocate actions and,
if possible, making memory in these regions available for use by future
finalization operations. (Some systems prohibit reuse of executable
memory. On these systems deallocated memory is no longer usable within
the process).
4. Release reserved slabs. This runs deallocate for any
not-yet-deallocated finalized regions, and then (if possible) returns
the address space to system. (On systems that prohibit reuse of
executable memory parts of the released address space may be permanently
unusable by the process).

SimpleNativeMemoryMap is intended primarily for use by
llvm::orc::JITLinkMemoryManager implementations to allocate JIT'd code
and data.

The ResourceManager interface can be used to implement ownership for resources
allocated to JIT'd code, e.g. memory and metadata registrations (frame info,
language runtime metadata, etc.).

Resources can be *deallocated*, meaning that they should be cleaned up (memory
released, registrations deregistered, etc.), or they can be *detached*, meaning
that cleanup should be performed automatically when the ResourceManager itself
is destroyed.

The intent is to allow JIT'd code to continue running after the
llvm::orc::ExecutionSession that produced it is disconnected / destroyed.

This commit contains executor-side support for ORC allocation actions
(see e50aea58d59).

An AllocAction is a function pointer with type
orc_rt_WrapperFunctionBuffer (*)(const char *ArgData, size_t ArgSize),
along with an associated blob of argument bytes.

An AllocActionPair is a pair of AllocActions, one to be run at memory
finalization time and another to be run at deallocation time.

The runFinalizeActions function can be used to run all non-null finalize
actions in a sequence of AllocActionPairs, returning the corresponding
sequence of deallocation actions on success.

The runDeallocActions function can be used to run a sequence of dealloc
actions returned by runFinalizeActions.