Support of AOT compilation (refine #6992)

[zpcore]

This is a follow up PR to refine #6992.

In this PR, I created the PjRtCompilationClient to serve the ahead of time compilation. In this way, we don't need to create the CompileOnlyPjRtClient, CompileOnlyPjRtDevice etc. This makes it easier during openxla pin update.

Instructions on how to run AOT compilation has been updated. We need to specify two extra flags when run on CPU device: XLA_PERSISTENT_CACHE_PATH as follows:
----------------------- ON CPU--------------------

PJRT_DEVICE=TPU   XLA_PERSISTENT_CACHE_PATH=./  python aot_encode.py

aot_encode.py:

import torch
import torch_xla
import torch_xla.core.xla_model as xm

torch_xla._XLAC._xla_set_virtual_topology("v4:2x2x1")  # <----- define virtual topology here. Must be specified before any device declaration.

a = torch.rand([2,3])
b = torch.rand([2,3])
device = xm.xla_device()
a = a.to(device)
b = b.to(device)
f = torch.hstack([a,b])

torch_xla._XLAC._xla_warm_up_cache([f],[])  # <----- call this to avoid real computation.

This will genereate a hashing file named like 229013763457648799216243727807636414712, which can be deserialized by running the same graph code on a TPU:
-----------------------ON TPU v4-8--------------------

PJRT_DEVICE=TPU XLA_PERSISTENT_CACHE_PATH=./  python aot_decode.py

aot_decode.py:

import torch
import torch_xla
import torch_xla.core.xla_model as xm

a = torch.rand([2,3])
b = torch.rand([2,3])
device = xm.xla_device()
a = a.to(device)
b = b.to(device)
f = torch.hstack([a,b])

print(f)

[will-cromar]

Since this state is only ever used by PjRtCompilationClient, would it make sense to make this a static field on PjRtCompilationClient?

I think it's probably even better to just imperatively initialize this client when set_virtual_topology() happens... but that also would introduce some extra edge cases for initialization. For the POC, a global var is okay, but I think a static field makes more sense to make it clear what uses that state.

[zpcore]

Moving aot_topology to pjrt_compilation_client.h may cause circular dependency issue because setting the aot_topology need to check g_computation_client_initialized in the current setup.

Let's use the global var for now since this makes it clear in runtime.cc that we have three kinds of clients all together.

[will-cromar]

I see some duplication of helpers here and in the PJRT/IFRT client implementations. It would be cleaner to factor it out rather than have 3 copies, but both AOT and IFRT are just in a concept stage...

I'll let @JackCaoG have the final word on readability so I don't have to decide.