sanitizers: Add documentation for the `no_sanitize` attribute

[rcvalle]

Add documentation for the no_sanitize attribute, being stabilized in rust-lang/rust#123617 along with AddressSanitizer and LeakSanitizer.

[ehuss]

Some drive-by questions:

• I'm not clear which options to the attribute are being stabilized. The PR says "leak" and "address", but there doesn't appear to be a "leak" option. Is address the only attribute option being stabilized? If so, that needs to be documented. And this PR is referring to the thread option, which doesn't appear to be stabilized? If so, then it shouldn't include that.
• Where can this attribute be placed? It seems to only validate its usage when there is an argument, which isn't how I would expect it to work.
• What is the behavior if the attribute is specified multiple times? Does it take the union of all options?
• I assume the attribute is ignored if the target does not support the sanitizer?
• Does this only work with build-std or custom std builds?

[rustbot]

:umbrella: The latest upstream changes (possibly f80986bb34aa67f30bbb6b92f7b69b250e275126) made this pull request unmergeable. Please resolve the merge conflicts.

[rcvalle]

Some drive-by questions:

• I'm not clear which options to the attribute are being stabilized. The PR says "leak" and "address", but there doesn't appear to be a "leak" option. Is address the only attribute option being stabilized? If so, that needs to be documented. And this PR is referring to the thread option, which doesn't appear to be stabilized? If so, then it shouldn't include that.

Thanks for pointing it out! I copied the documentation from The Unstable Book and missed it. I'll fix it. (Yes, address is the only attribute being stabilized for now.)

• Where can this attribute be placed? It seems to only validate its usage when there is an argument, which isn't how I would expect it to work.

It can be placed on globals and functions.

• What is the behavior if the attribute is specified multiple times? Does it take the union of all options?

No, I believe it takes the last, but I'll double check.

• I assume the attribute is ignored if the target does not support the sanitizer?

Yes.

* Does this only work with build-std or custom std builds?

No, it provides incremental value without requiring rebuilding the Rust Standard Library (i.e., Cargo build-std feature), and it's usually where it interests more the user (i.e., the code being developed). That said, we'll provide pre-build standard libraries for each sanitizer when stabilizing the MemorySanitizer and ThreadSanitizer next.

I've created a Zulip thread for us to discuss the next steps and stabilizing the no_sanitize attribute.