doc: improve explanation of unsafety for atomic mode

[mflatt]

Closes #4858

[LiberalArtist]

I don't recall many specific questions offhand, but I know I have sometimes felt unclear about the distinctions (if any) between atomic mode and some other sets of restrictions (most of which include atomic mode) related to ffi/unsafe:

• #:async-apply arguments to _cprocedure or _fun
• callbacks created with #:atomic #t—are these additional restrictions, or just further examples of the restrictions of atomic mode?

  In addition, the Racket code must not perform any potentially blocking operation (such as I/O), it must not raise an uncaught exception unless called through a callout that supports exception (with #:callback-exns? #t), it must not perform any escaping continuation jumps, and (at least for the BC implementation) its non-tail recursion must be minimal to avoid C-level stack overflow; otherwise, the process may crash or misbehave.

• Functions called in an unspecified Racket thread, e.g. the callback for register-custodian-shutdown
• Finalizers for register-finalizer
• Functions used with call-in-os-thread

[mflatt]

I agree that more is needed here. For example, there's some duplication in the description of #:atomic, but there are also additional restrictions about escaping and C-level overflow in that context.