#162872 Large fallout from semicolon_in_expressions_from_non_local_macros

The semicolon_in_expressions_from_macros lint has existed since forever; see https://github.com/rust-lang/rust/pull/159218 for details. The lint was slowly ramped up over the course of more than 4 years. However, it only ever warned about macros defined in the crate they are used.

The following changes were made during the 1.99 development window:

The old lint was extended to also fire if crate A uses a macro from crate B that has the semicolon problem (deny-by-default, report-in-deps).
This caused a lot of errors so the cross-crate case was split into a separate lint, semicolon_in_expressions_from_non_local_macros (warn-by-default, report-in-deps).
After beta branched off, that new lint was downgraded to warn-by-default, no-report-in-deps. (This has not landed yet in the beta branch but should land soon.)

This means that in Rust 1.99, we will have a new lint semicolon_in_expressions_from_non_local_macros that also fires if crate A uses a macro from crate B that has the semicolon problem. This lint is warn-by-default and does not show up in deps. In current nightly, which will become Rust 1.100, the lint is marked as report-in-deps (while remaining warn-by-default). That is a rather quick ramp-up for a lint that is triggered widely across the ecosystem:

It triggered in two independent cases even in dependencies of the rustc workspace.
https://github.com/rust-lang/rust/issues/79813 started getting a huge amount of backlinks when we started linting the non-local case on July 15th.
Anecdotally, multiple people reported on Zulip that they encounter this lint way above the usual rate at which they encounter FCW.

Additionally, the reports one gets for this lint from dependencies are quite confusing, by nature of this being about macros: if the lint triggers in crate A when using macro M, then the actual issue is in crate B that defined the macro. A user just sees "the version of nix you are using will stop compiling in the future", but what they don't know and cannot easily find out is that they actually have to update cfg_aliases to make this warning disappear.

So, given all that... maybe we should slow down a little, and not ramp up the lint for the non-local case from "nothing" in 1.98 to "report in deps" in 1.100, over a mere two releases? It is anyway rather odd that the lint is warn-by-default but also report-in-deps; if we think it is too invasive to make it deny-by-default then maybe it is too early to make it report-in-deps. I think what happened is that people didn't realize that for 4 years we only linted for the local case, and when they realized they wanted to quickly add the non-local case to not slow down the cleanup that is blocked on this FCW... but I don't think that's a good enough reason to rush semicolon_in_expressions_from_non_local_macros as much as we are currently rushing it, given the fallout this is causing.

A crater run turning both lints into hard errors has been queued, to figure out the overall effect on the ecosystem.

@rust-lang/lang so given what we now know about the fallout of semicolon_in_expressions_from_non_local_macros, how would you like to proceed?

Keep it as report-in-deps for Rust 1.100,
or slow down and make it not-report-in-deps for now, let it bake for a bit, and then eventually bump it to deny + report-in-deps?

If we do nothing, then in 8 weeks Rust 1.100 will be released with the first option.