Deprecate ActorNursery.run_in_actor() and offer as part of a wrapper cluster API

[goodboy]

I've rambled on wayyy too long in #287 but thanks to attempts to resolve that issue I think this is the way I'd like to go on a so called one shot task per actor-style "worker pool" API.

TDLR premises

• Portal.result() + ActorNursery.run_in_actor() couples a future-like API into our nursery's actor spawning interface at the wrong level of abstraction
• .run_in_actor() can be implemented as a syntactic sugar on top of ActorNursery.start_actor() + Portal.run() using trio tasks in a similar way to our concurrent.futures worker pool example
• conducting error collection and propagation in our ActorNursery's teardown machinery is entirely superfluous and a path dependent legacy design which has a few pretty awful side effects:
  • it makes the nursery need to be aware of .run_in_actor() portals
  • it enforces duplication between .run_in_actor() and Portal.run()
  • it complicates spawn machinery with special cases
  • it results in hard to maintain tests due to indeterminacy in cancelled vs. errored child results (which btw won't go away if we change the API layering but at least we can leverage std trio nursery machinery instead of rolling our own 😂)

ToDO

• write up a version of .run_in_actor() style on top of the rest of the nursery API
• convert the nested_multierrors() test to use the .open_context() / .run() style and ensure we can still get as reliable of performance
• figure out how to offer the higher level / new .run_in_actor() API as a cluster helper

[goodboy]

A name came to me this morn:

• async with tractor.open_task_pool() as cluster: or .open_actor_task_pool(), or we just do a simple .open_actor_cluster() as cluster: ?
• provide a Cluster.run_in_actor()?