Allow `deprecated_in_future` lint to specify an indeterminate future deprecation date

[bstrie]

In #78335 there was discussion regarding a first-class "soft deprecation" mechanism.

For background, currently the numeric constants in the primitive-shadowing std modules (e.g. std::u8::MAX) have been superseded by associated constants (#68490). The old constants have been "soft deprecated", which is to say that their documentation suggests the new alternatives, but there is no lint or compiler warning implemented to suggest this.

The obvious next step would be to deprecate these constants, but the deprecation lint is warn-by-default, and some members of the libs team are concerned that this is too minor of a change to justify warnings (outside of an edition, anyway).

There is a more gradual change that should be more palatable: the deprecated_in_future lint (#56203). This lint differs from deprecation in that it is allow-by-default rather than warn-by-default. It would allow users to opt-in to warnings (useful for, e.g., the compiler itself: #78380). Furthermore this lint has the additional benefit of being as visible in the docs as an ordinary deprecation, which is a primary concern of #68490. It's the perfect middle ground to resolve the tension here.

However, the deprecated_in_future lint is triggered by giving the usual rustc_deprecated attribute a since value in the future. For the purpose of maximum political expedience, it would be nice in this instance to not have to determine an actual specific deprecation date, and merely suggest that it will be deprecated "eventually".

In particular, a release coinciding with an edition seems like a natural time to deprecate, but we won't know exactly which release that will be until much closer to the edition date. In the interim it seems a shame that such scheduling details should prevent users from opting-in to deprecation warnings.

If such a feature existed, we can imagine that it would have already naturally been employed when the documentation of std::u8::MAX et al was originally changed to mention "soft deprecation".

I propose that the rustc_deprecated attribute should be able to accept a since value of "TBD", in order to trigger the benefits of the deprecated_in_future lint without having to commit to a concrete deprecation date.

[DJMcNab]

This appears to have been stabilised for user code (i.e. #[deprecated(since = "TBD")]) in 1.75 (presumably in #117377). However, I've been unable to find anything documenting this, other than perhaps #118148.

Is this a feature that we can rely on as crate authors?

See e.g. (playground):

#![allow(unused)]
#[deprecated(since = "TBD")]
fn test(){}

#[warn(deprecated_in_future)]
fn uses_deprecated_defensively() { test() }
fn uses_deprecated() { test() }

which gives the following warning:

   Compiling playground v0.0.1 (/playground)
warning: use of function `test` that will be deprecated in a future Rust version
 --> src/lib.rs:6:36
  |
6 | fn uses_deprecated_defensively() { test() }
  |                                    ^^^^
  |
note: the lint level is defined here
 --> src/lib.rs:5:8
  |
5 | #[warn(deprecated_in_future)]
  |        ^^^^^^^^^^^^^^^^^^^^

warning: `playground` (lib) generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s

That is, the since = "TBD" supresses the deprecated lint