This commit adds operations to orc::MemoryAccess for reading basic types
(uint8_t, uint16_t, uint32_t, uint64_t, pointers, buffers, and strings)
from executor memory.

The InProcessMemoryAccess and EPCGenericMemoryAccess implementations are
updated to support the new operations.

This moves the MemoryAccess interface out of the ExecutorProcessControl
class and splits implementation classes InProcessMemoryManager and
SelfExecutorProcessControl out of ExecutorProcessControl.h and into
their own headers.

Make EPCGenericMemoryAccess the default implementation for the MemoryAccess
object in SimpleRemoteEPC, and add support for the WritePointers operation to
OrcTargetProcess (previously this operation was unimplemented and would have
triggered an error if accessed in a remote-JIT setup).

No testcase yet: This functionality requires cross-process JITing to test (or a
much more elaborate unit-test setup). It can be tested once the new top-level
ORC runtime project lands.

Identified with misc-include-cleaner.

This keeps common operations together, and should make it easier to write
re-usable dylib managers in the future (e.g. a DylibManager that uses
the EPC's remote-execution APIs to implement load and lookup).

Switch the primary implementation of EPC lookupSymbols to be async,
keeping a synchronous wrapper for compatibility. Use the new async
implementation inside EPCDynamicLibrarySearchGenerator to work
working towards a fully async search generator.

Provide an asynchronous lookup API for EPCGenericDylibManager and adopt
that from the SimpleRemoteEPC. This enables an end-to-end async
EPCDynamicLibrarySearchGenerator. Note: currently we keep the current
per-dlhandle lookup model, but a future improvement could do a single
async call for a given lookup operation.

SimpleRemoteEPC already included a "bootstrap symbols map" that could be used
to communicate the addresses of symbols needed for JIT bootstrap. The new
bootstrap map can be used to communicate arbitrary bootstrap values (encoded as
SPS buffers).

The bootstrap symbols map is kept as distinct becasue bootstrap symbols are
significant, and having a known value type for them allows for better debug
logging (we know how to render the values) and tooling (e.g. utils for adding
all bootstrap symbols to a JITDylib).

Most ORC APIs work with ExecutorAddr by default since 8b1771bd9f3, so we don't
need to wrap these values in ExecutorAddr(...) calls any more.