Add ability to define custom runtime classes

[raymyers]

• This change is worth documenting at https://docs.all-hands.dev/
• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

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

Allow advanced users to define their own custom runtimes.

---

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

The motivating use case is to allow hosted implementations to watch events for monitoring purposes, without depending on a monitoring SDK in this codebase. (First try PR, with some discussion). That leads to a desire to subclass a Runtime implementation, overriding on_event to add monitoring.

However, currently only a hard-coded mapping of existing Runtime classes may be configured. This PR allows a fully-qualified class-name to be specified instead. For example:

#  Default:
# runtime = "docker"

runtime = "app.mystuff.CustomRuntime"

I've chosen to only document this new option in the runtime module README, not the config template.

Change: The e2b runtime name was returning the E2Box class before, a type error which probably did not work. It's now mapped to E2BRuntime.

Future: If we wanted, this would allow us to move some of the existing runtime implementations from parts of the codebase into usage examples, so we do not have to make every user depend multiple vendor SDKs they aren't using.

---

Link of any specific issues this addresses.

[enyst]

This PR seems related maybe, WDYT?

• [Feature] Refactor runtime executor for better extensibility/configurability #6297

[raymyers]

Interesting feature gap behind this type ignore (needless rabbithole though).

python/mypy#4717

[raymyers]

@enyst

This PR seems related maybe, WDYT?

• [Feature] Refactor runtime executor for better extensibility/configurability #6297

Neat, I hadn't seen that one yet. It's related but a bit different, because what it's refactoring into ActionExecuter is associated with ActionExecutionServer, and the Runtime classes are ActionExecutionClient which calls it. So that PR impacts "what do you run", and this one is about "where do you run it".

But given that it's similar class selection config some consistency would be nice. A way I could make this one more consistent would be use only the existing runtime config var, and say if you don't specify one of the known values you can use a class name. (Edit: This simplification is done)

[enyst]

I think this is a nice PR, thank you! I particularly like how the implementation keeps things readable, and you are entirely correct, consistency with the other PR is really good to have.

I'd love to know how @rbren thinks about this.

[rbren]

This seems useful!