We don't reject const auto traits

[fmease]

Auto traits are just markers, mere flags. Marking them const doesn't serve much purpose. If you're longing for AutoBound vs. const AutoBound, just introduce another auto trait: AutoBound vs. AnotherAutoBound. The utility of [const] AutoBound is also questionable to me.

Moreover, today, the constness of auto traits doesn't "propagate" (i.e., built-in auto trait impl candidates are always non-const), so one can't actually benefit from the autoness of the const trait. We should keep it that way IMO & forbid const auto traits, not sure if anybody would disagree.

As an aside, we currently intentionally panic in the next-gen solver when trying to prove a host effect predicate where the corresp. trait is auto:

// -Znext-solver
#![feature(auto_traits, const_trait_impl)]

const auto trait Marker {}

fn scope() {
    fn check<T: const Marker>() {}
    check::<()>();
}

thread 'rustc' (6486) panicked at /rustc-dev/c23ed3ef28b3cc30658310f771ddc66e5b687cf4/compiler/rustc_next_trait_solver/src/solve/effect_goals.rs:195:9:
internal error: entered unreachable code: auto traits are never const

Just opening this so we don't lose track of this.

[oli-obk]

Ah yea, we should reject those in ast validation