Tracking issue for release notes of #159700: Split non-local `semicolon_in_expressions_from_macros` into a separate lint

This issue tracks the release notes text for #159700.

cc @joshtriplett, @wesleywiser, @petrochenkov -- original issue/PR authors and assignees for drafting text

See the forge.rust-lang.org chapter about release notes for an overview of how the release team makes use of these tracking issues.

Release notes text

This section should be edited to specify the correct category(s) for the change, with succinct description(s) of what changed. Some things worth considering:

• Does this need an additional compat notes section?
• Was this a libs stabilization that should have additional headers to list new APIs under Stabilized APIs and Const Stabilized APIs?

# Language
- Macros that expand to a semicolon now produce a warning lint (`semicolon_in_expressions_from_non_local_macros`) even when the macro comes from another crate. Previously, such warnings only appeared for macros from the same crate, to avoid showing warnings that can't be fixed locally; however, this masked problems, as integration tests from the crate providing the macro get compiled as a separate crate, so tests often wouldn't reveal this issue. If you encounter a lint like this, please make sure to report it to the crate providing the macro so they can fix it; don't just silence it in your own crate.
  - [semicolon_in_expressions_from_macros: Lint on non-local macros too](https://github.com/rust-lang/rust/pull/159222)
  - [Split non-local `semicolon_in_expressions_from_macros` into a separate lint](https://github.com/rust-lang/rust/pull/159700)

[!TIP]
Use the previous releases for inspiration on how to write the release notes text and which categories to pick.

Release blog section

If this change is notable enough for inclusion in the blog post then this section should be edited to contain a draft for the blog post. Otherwise leave it empty.

## Non-local macros expanding to a trailing semicolon now lint in expression context

When a macro's expansion ends with a semicolon, expanding the macro in a context that expects an expression results in a lint:

```rust
macro_rules! ends_in_semicolon {
    () => { 42; }
}

fn main() {
    let _x = 123 + ends_in_semicolon!() + 456;
}
```

We've warned about this for many years, and as of Rust 1.91 the lint defaults to `deny`. However, historically we've only shown this warning for macros coming from the same crate, and suppressed it for non-local macros, to avoid showing warnings that can't be fixed locally in your crate:

```rust
// In `other_crate`
#[macro_export]
macro_rules! ends_in_semicolon {
    () => { 42; }
}

// In your crate
fn main() {
    // Not warned in previous versions of Rust.
    // Warned as of Rust 1.99, using the separate lint `semicolon_in_expressions_from_non_local_macros`.
    let _x = 123 + other_crate::ends_in_semicolon!() + 456;
}
```

This masked some problems, in part because a library's integration tests get compiled as separate crates, so tests often wouldn't reveal this issue. 

We now lint about macros whose expansion includes a trailing semicolon, even if they come from another crate. Such macros will produce the new warning lint (`semicolon_in_expressions_from_non_local_macros`). (This lint starts out at `warn`, since it's new in this release of Rust.) If you maintain a library crate with macros, please consider adding tests invoking your macros, which will now catch such issues.

If you encounter a lint like this coming from a macro not in your crate, in some cases you can work around it by invoking the macro in a different (non-expression) context, or invoking the macro using braces (`the_macro! { .. }`) rather than parentheses. In other cases, you may not be able to fix it directly, and it will need fixing in the upstream crate, so you'll likely need to `allow` it temporarily. However, before you add an `allow`, please make sure to report it to the crate providing the macro so they can fix it. (Check for duplicate reports before doing so, and for newer versions of the crate, as other users of the crate may have already reported it.)

[!NOTE]

If a blog post section is required the release-blog-post label should be added (@rustbot label +release-blog-post) to this issue as otherwise it may be missed by the release team.

Start with the forge.rust-lang.org release-notes guidance and compare the proposed text with previous releases at doc.rust-lang.org/nightly/releases.html. Review the Release notes text and Release blog section in this issue for accurate categories, compatibility notes, and whether the blog section is needed. Done means the release wording is concise and correctly categorized, with the release-blog-post label added if applicable.