sasl: suspend processes concurrently during release upgrades

[v0idpwn]

Adds sys:multi_suspend/1,2 and use it in release_handler_1 to send suspend requests in parallel instead of one at a time.

I'm not sure about the new API in sys, but it felt like the cleanest way to do it. Appreciate any takes on it.

Closes #11001

[github-actions]

CT Test Results

    3 files    104 suites   1h 13m 12s ⏱️
2 327 tests 2 276 ✅ 51 💤 0 ❌
2 730 runs  2 673 ✅ 57 💤 0 ❌

Results for commit da4248c.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• No Windows Installer found

// Erlang/OTP Github Action Bot

[RyanJamesStewart]

Two test additions on top of this PR if useful. Branch: tests/11009-multi-suspend-timeout (or view as compare-against-master; rebased onto the PR head).

sys_SUITE:multi_suspend_timeout/1 covers the {error, timeout} clause of sys:multi_suspend/2; the existing multi_suspend test only exercises the ok and exit-during-suspend clauses.

release_handler_SUITE:release_handler_1_suspend_safety_net/1 drives release_handler_1:suspend/3 with one slow worker and one prompt worker, asserts the timed-out worker is left runnable by the safety-net catch sys:resume(Pid) on the timeout branch, and asserts the result list contains the prompt pid only. Mirrors supervisor_which_children_timeout/1 in the same suite (direct call + observable post-state, no tracing). The two-worker fixture discriminates both-branches-fail from both-branches-ok.

release_handler_1:suspend/3 is added to the export list with the same convention comment used for get_supervised_procs/0.

Happy to fold into this PR via cherry-pick or amend, open as a separate PR, or drop the suggestion entirely. Whatever fits.