Disallow future-incompatibility lints in the 2024 edition

[tmandry]

We have quite a long list of future-incompatibility lints that are waiting to be made into hard errors. The lints are so severe that we warn even when they are used by a dependency of the crate being built, because they will cause the crate to stop compiling at some point in the future.

We could use the edition as an impetus to switch some or all of these lints over to hard errors (or deny-by-default lints). Note that because of the way editions work this would only affect the crate being upgraded, not its dependencies. This would mean pairing the carrot with the stick, so to speak; if any of the crates triggering these errors are upgraded to the edition they will also need to have their future-incompat issues fixed. It also means that new code (using the latest edition) won't be written that triggers these lints.

On the other hand it's unlikely that the crates with future-incompat issues are being maintained in the first place, so this wouldn't do much to help the problem.

Opening this issue for discussion and consideration by the lang team.

For some background on how we handled this in past editions, see #80165 (comment).

[tmandry]

Discussed in yesterday's lang team meeting; the consensus was that we would consider moving the lints to breaking errors in logical batches or individually, but not as one group.