Redesign ORC's query system

Instances of [`AsynchronousSymbolQuery`](https://github.com/llvm/llvm-project/blob/06aae40c6dee03741f96c1b09ccc57f7fb110dd1/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L802) are created by `ExecutionSession::lookup` calls, and stored in the `JITDylib` symbol tables until the queried symbols reach the required state, at which point the query's callback is called (passing a `SymbolMap` result). Separately, `ExecutionSession::lookup` takes a `RegisterDependenciesFunction` that reports the JITDylib that each symbol was found in. This scheme unnecessarily couples _lodging_ of a query with _execution_ of that query: We can't find out what JITDylibs a query's symbols will be found in without immediately triggering materialization of those symbols. Separating these operations would permit a nice optimization in JITLink.

Today, each JITLink instance has to issue `lookup` calls in its post-allocation phase because it can't safely trigger materialization of other symbols until it has published the addresses of its own symbols (failure to do so could result in deadlock).

If we separate lodging and execution of queries the following scheme becomes safe:

1. Post-pruning but pre-allocation, JITLink lodges a query for all external symbols. The `lodge` operation reports the JITDylib that defines each symbol and this information is reflected in the LinkGraph.
2. Post-allocation (after the instance publishes its own symbol definitions) the JITLink instance can `execute` the query that it built in step 1 to find the addresses of the externals.

This separation would save JITLink from having to conservatively allocate GOT/PLT entries for references to other code in the same JITDylib (at least where JITLink knows that memory allocated within a JITDylib will be in-range according to the code-model)