#3619 Document when a caller-supplied request id can be minted again

Fixes #3126.

This documents the contract of CallOptions["request_id"] rather than changing how ids are numbered. The docstring now says what the dispatcher does and doesn't promise about a supplied id:

• A supplied id never clashes with another in-flight request: supplying one that is in flight raises ValueError, and the dispatcher's own counter skips it.
• Integer ids and numeric strings share the dispatcher's counter, so the same value can be minted again once that request has finished.
• When an id has to stay unique for the whole session, use a string that doesn't parse as an integer, as the subscriptions/listen driver does with listen-1, listen-2 and so on.

I looked at fixing this in code and decided against it. Remembering every supplied id grows without bound for a caller that supplies one per request, and moving the counter past supplied ids changes the minted sequence for exactly the callers who use this option.

Docstring only, no behaviour change.

_{AI Disclaimer}