Allow monitor options in proc_lib:start_monitor/5

[Maria-12648430]

Currently, the spawn options monitor and {monitor, MonitorOpts} are disallowed in the proc_lib:start* functions. This goes back all the way to R11, a ticket OTP-6345, and this post on the old Erlang ML.

For proc_lib:start_monitor, it makes no sense to forbid monitor options. Or at least, we don't see any benefit in doing so. On the contrary, it prevents "customizing" the monitor (eg custom tags, usage of the new priority option, etc). This PR removes this restriction.

For proc_lib:start and proc_lib:start_link, it would be possible to remove the restriction also, that is, without restoring the buggy behavior that seems to have given raise to OTP-6345.
However, in the presence of a monitor or {monitor, MonitorOpts} spawn option, the return value would change from Ret to {Ret, Mon}, with repercussions via gen into the start/start_link functions of the gen_* behaviors.
This may be ok, and require mostly work on the specs and documentation in the gen_* behaviors, aside from some adaptions in gen. The bigger question IMO is if and how supervisors should cope with this?

---

This PR also does a few more things than what is listed above, which are related to the new {link, LinkOpts} spawn option that appeared with the new priority messages. Those are mostly just documentation changes.

[github-actions]

CT Test Results

    2 files     97 suites   1h 5m 55s ⏱️
2 207 tests 2 155 ✅ 52 💤 0 ❌
2 585 runs  2 529 ✅ 56 💤 0 ❌

Results for commit 6d9d85b.

♻️ 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