`rustc_const_unstable` on private items is confusing

Problem

Right now, private items that use const-unstable things need one of the following:

1. rustc_const_unstable, to mark them as part of an unstable feature
2. rustc_const_stable_indirect, to mark these uses of const-unstable features as okay to be used indirectly in const-stable functions

This can be particularly confusing when trying to assign features to these functions, since in particular, either of these attributes is okay to add to any private item, regardless of whether they actually need it.

The main issue is that we want to track what const features are indirectly exposed to stable, but that we don't want to recursively inspect function bodies to do this.

Proposal

So, I propose a new solution: rustc_forward_const_fn_unstable.

This is similar to rustc_allow_const_fn_unstable, but specifically for private items, and it has slightly different semantics:

1. The features mentioned in the attribute must exist, be unstable, and be used in the body of the function.
2. After being processed, the function is treated as unstable with all the different features listed. (and the correct issues)

This effectively punts a rustc_allow_const_fn_unstable attribute down the line to a caller function if needed, helps avoid the issue where people just add the same const unstable feature to all methods they need it on, and avoids unnecessarily adding unstable features to const methods that don't require them.

Effectively, it bypasses the issue discussed in this review thread.

Start by reading the existing rustc_allow_const_fn_unstable behavior described in the issue and the linked review thread. Identify the compiler entry points and tests that govern rustc_const_unstable and rustc_const_stable_indirect, then determine how the proposed rustc_forward_const_fn_unstable semantics should be validated. Done means the new attribute enforces the stated feature checks and forwarding behavior without recursive body inspection.