The endian_read and endian_write operations read and write unsigned
integers stored in a given endianness.

Can be used to test that one address range is fully contained within
another. This is an orc-rt counterpart to aa731e19045, which added the
same operation to llvm::orc::ExecutorAddrRange.

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 replaces SPS transparent conversion for pointers. Transparent
conversion only applies to argument/return types, not nested types. We
want to be able to serialize / deserialize structs containing pointers.

We may need to replace this in the near future with a new SPSPointer tag
type, since SPSExecutorAddr is meant to be serialization for pure
addresses, and pointers may carry other information (e.g. tag bits), but
we can do that in a follow-up commit.

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.

SPS deserialization for span<const char> produces a value that points
directly into the argument buffer for efficiency. This was broken by an
unnecessary std::move of the buffer inside WrapperFunction, which this
commit removes.

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).