Allow multiple `do_node_execute` adapters

[tfrancisl]

Is your feature request related to a problem? Please describe.
I am trying to use Hamilton caches with a custom implementation of the GracefulErrorAdapter already available in Hamilton. Since both caching and the error handling adapter use the do_node_execute hook, driver instantiation fails when specifying a cache and the error handling adapter.

Describe the solution you'd like
I would like to be able to instantiate a Hamilton driver with more than one adapter using the do_node_execute hook. The behavior of the driver would then depend on some precedence for the order in which the adapters wrap the node. This precedence would likely be determined by considerations within Hamilton, but should be fairly obvious to the user.

Describe alternatives you've considered

Subclassing the base Hamilton driver myself and implementing my custom error adapter within this subclass.

• + Unblocks me right away
• - Docs indicate we should avoid making custom drivers.
• - Defeats the purpose of providing the with_adapter(s) interfaces on the drivers. Adapters should be "chainable"/composable.

Not using caching

• - Makes my pipelines slower on reruns, no benefit from code versioning etc.
• + No maintenance cost or complexity for metadata store or result store.

Not using an error handling adapter

• - Any failure within one node in the pipeline means no results for any nodes. This is awful when we have nodes which will fail under certain conditions but should not cause the pipeline to fail.
• - Achieving "graceful" error handling otherwise (i.e., error checking in every node) increases code complexity with little gain.

Additional context

Less relevant to the feature request:
The primary change my GracefulErrorAdapter implementation makes from the Hamilton implementation is passing context about the error forward instead of just a sentinel value. I'm making a Hamilton pipeline that has lots of finnicky computer vision code within which is usually not worth writing complex error checking for. I wouldn't mind contributing this adapter to the project so that I can get more eyes on it.

[skrawcz]

Yep this change might be involved, but definitely a known limitation of the current design.