[core][experimental] Add experimental compiled DAG

[stephanie-wang]

Why are these changes needed?

This adds an experimental interface that allows you to compile a normal ray.dag to use a faster execution path. The execution path uses ray.experimental.channel to pass data directly between actors instead of going through the normal Ray control plane. See the REP for more information.

Several limitations will be addressed in a follow-up PR:

1. dag.execute returns a Channel instead of an ObjectRef. Reading from a Channel requires the caller to release the value as soon as they are done with it, to avoid blocking the next DAG execution.
2. Single-node only.
3. Actors can only execute one DAG. Once they begin executing, they cannot execute other tasks and must be killed to stop executing. An actor can have at most one task in a DAG.

Initial results show about 35x speedup compared to normal Ray core on simple single-node DAGs:

single-actor DAG calls per second 593.42 +- 32.8
compiled single-actor DAG calls per second 20931.29 +- 675.78
scatter-gather DAG calls per second 248.87 +- 4.06
compiled scatter-gather DAG calls, n=4 actors per second 8896.79 +- 92.42
chain DAG calls, n=4 actors per second 156.48 +- 14.11
compiled chain DAG calls, n=4 actors per second 5738.39 +- 219.31

[ericl]

Explain the concern about circular dependencies here?

[edoakes]

you can add a simple wrapper for weakref to address the serialization issue if it's needed. I did the same in a patch to the pydantic repo: pydantic/pydantic#7780

[edoakes]

What is the _ray_system concurrency group and why's it required here?

[ericl]

We shouldn't need to declare this group, it's automatically created per #41605