Revise editorially

In most of the examples for these attributes, there's no lead-in, so
let's remove the lead-in here.

Let's also say "form" rather than "thing", even though "thing" does
have a certain appeal to it.

In our rule for duplicates, let's add a forward reference to the
exception to that.

Finally, we say that the attribute applied at the crate level does not
remove the crate; later, for an example, let's clarify that it only
removes the content of the crate.

Most or all of this was preexisting to this PR.

Author: traviscross

src/conditional-compilation.md

@@ -322,8 +322,6 @@ r[cfg.attr.intro]
 The *`cfg` [attribute]* conditionally includes the thing it is attached to based on a configuration predicate.
 
 > [!EXAMPLE]
-> Some examples of using `cfg` on functions:
->
 > ```rust
 > // The function is only included in the build when compiling for macOS
 > #[cfg(target_os = "macos")]
@@ -368,7 +366,7 @@ r[cfg.attr.allowed-positions]
 The `cfg` attribute is allowed anywhere attributes are allowed.
 
 r[cfg.attr.duplicates]
-Multiple `cfg` attributes may be specified. The thing will not be included if any of the `cfg` predicates are false.
+Multiple `cfg` attributes may be specified. The forms to which the attribute are applied will not be included if any of the `cfg` predicates are false except as described in [cfg.attr.crate-level-attrs].
 
 r[cfg.attr.effect]
 If the predicate is true, the thing is rewritten to not have the `cfg` attribute on it. If the predicate is false, the thing is removed from the source code.
@@ -377,7 +375,7 @@ r[cfg.attr.crate-level-attrs]
 When a crate-level `cfg` has a false predicate, the crate itself still exists. Any crate attributes preceding the `cfg` are kept, and any crate attributes following the `cfg` are removed as well as removing all of the following crate contents.
 
 > [!EXAMPLE]
-> The behavior of not removing the preceding attributes allows you to do things such as include `#![no_std]` to avoid linking `std` even if a `#![cfg(...)]` has removed the entire crate. For example:
+> The behavior of not removing the preceding attributes allows you to do things such as include `#![no_std]` to avoid linking `std` even if a `#![cfg(...)]` has otherwise removed the contents of the crate. For example:
 >
 > <!-- ignore: test infrastructure can't handle no_std -->
 > ```rust,ignore