Add `deliver_cancel` parameter and `start` support to `run_process`

### Things to check first

- [X] I have searched the existing issues and didn't find my feature already requested there

### Feature description

Trio

1. has a `deliver_cancel` parameter and `nursery.start` support in `run_process`
1. changed their examples to suggest that folks use `process = await nursery.start(run_process, ...)` instead of `open_process`.
1. moved `open_process` to `lowlevel`
1. removed `Process.aclose`

### Use case

* `process = await nursery.start(trio.run_process, ...)` actually enforces structured concurrency—you can't accidentally leave an orphan process[^1]
* `open_process` does not enforce structured concurrency, hence it should be in `lowlevel`. while you can make it enforce structured concurrency by doing `async with await trio.lowlevel.open_process() as process`, `process = await trio.lowlevel.open_process()` by itself does not use structured concurrency and is basically `fork()` without a `finally: wait(pid)` to follow it. hence i lean toward agreeing that `open_process` should be in `lowlevel`.

[^1]: except if the parent gets `SIGKILL`/`TerminateProcess` and can't run any `except/finally/__exit__/__aexit__/atexit` code.

i'd like to propose doing (1) and (2) in AnyIO: adding `deliver_cancel` support and `TaskGroup.start` support to `run_process`. i actually ended implementing this some months ago in a downstream AnyIO application at work, because upon cancellation we needed to send the child a gentle `SIGINT` first instead of reaching straight for `SIGKILL` and causing data loss. i'd be happy to move that implementation upstream if it seems reasonable.

if proposals (1) and (2) are accepted, AnyIO could also consider doing (3) and/or (4). they also make sense to me, as mentioned above—put `open_process` in `lowlevel` so users think twice before shooting themselves in the foot with the gun-that-orphans-processes.

thoughts?