Namely distinguishing service "IPC contexts" (opened in a
subactor via a `Portal`) from just local `trio.Task`s started
and managed under the `.service_n` (more or less wrapping in the
interface of a "task-manager" style nursery - aka a one-cancels-one
supervision start).
API changes from original (`piker`) impl,
- mk `.start_service_task()` do ONLY that, start a task with a wrapping
cancel-scope and completion event.
|_ ideally this gets factored-out/re-implemented using the
task-manager/OCO-style-nursery from GH #363.
- change what was the impl of `.start_service_task()` to `.start_service_ctx()`
since it more explicitly defines the functionality of entering
`Portal.open_context()` with a wrapping cs and completion event inside
a bg task (which syncs the ctx's lifetime with termination of the
remote actor runtime).
- factor out what was a `.start_service_ctx()` closure to a new
`_open_and_supervise_service_ctx()` mod-func holding the meat of
the supervision logic.
`ServiceMngr` API brief,
- use `open_service_mngr()` and `get_service_mngr()` to acquire the
actor-global singleton.
- `ServiceMngr.start_service()` and `.cancel_service()` which allow for
straight forward mgmt of "service subactor daemons".
5f5e9bad27