Factor out ActionExecutionClient

[rbren]

End-user friendly description of the problem this fixes or functionality that this introduces

• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below
  no changelog

---

Give a summary of what the PR does, explaining any non-trivial design decisions

This should be a straight refactor, but it's a little heavy. There's a TON of shared logic between all the different runtimes that just send HTTP requests to the ActionExecutionServer. This tries to factor all that out into a common place

There are probably some minor differences wrt retry logic and error handling, but I've tried to keep them the same

---

Link of any specific issues this addresses

---

To run this PR locally, use the following command:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:73063c8-nikolaik   --name openhands-app-73063c8   docker.all-hands.dev/all-hands-ai/openhands:73063c8

[enyst]

Can we add the change in this PR to the documentation, e.g. in the runtime README?

[xingyaoww]

Most thing LGTM! Do we keep the LogStreamer log in the client or still in each runtime implementation?

[rbren]

Oh does the LogStreamer use the API now, instead of docker logs? If so we can centralize it!

[rbren]

Seems like no--we need different log logic for docker, remote, modal, etc.

Mostly it seems like LogStreamer is a convenience when running locally, so only DockerRuntime has it for now. I removed the Modal and Runloop implementations since they're unused and hard to maintain

[rbren]

@xingyaoww lmk if you have any other concerns!

[xingyaoww]

This LGTM!

[xingyaoww]

Can we do a global replace in evaluation folder as well?