Permit trait object types where all (non-generic) associated constants are specified (via assoc item bindings)

[fmease]

Important context: Inherently, this would only become legal under the ongoing lang experiment associated_const_equality (#92827).

We permit trait object types where all 'active'¹ non-generic associated types are specified (via assoc item bindings). We should extend this to cover 'active' non-generic² associated constants, too.

Note that I haven't spent much time thinking about soundness yet. I still need to iron out the exact rules. Implementation-wise, I'm almost certain that any advances are blocked by #120905 (more precisely, its underlying issue) which I presume we would need to fix first for correctness.

Minimal & contrived example of something that would start compiling:

#![feature(associated_const_equality)]

trait Trait {
    const K: ();
}

fn main() {
    let _: dyn Trait<K = { () }>;
}

Presently, this gets rejected and we emit E0038 (cannot be made into an object).

---

Lastly, lest I forget, we should emit the lint unused_associated_type_bounds³ (#112319) for assoc const bindings where the corresp. assoc const is 'disabled' via where Self: Sized which is only possible to write under generic_const_items (#113521).

---

Footnotes

1. I.e., not 'made inactive' / 'disabled' via where Self: Sized (Don't require associated types with Self: Sized bounds in dyn Trait objects #112319). ↩

2. This might or might not be a temporary restriction. For context, we don't (yet) permit GAT bindings in trait object types either on stable, due to soundness concerns. See generic_associated_types_extended (Tracking Issue for extended generic associated types #95451). Also note that generic assoc consts (GACs) are only available under generic_const_items (Tracking issue for generic const items #113521). ↩

3. Indeed, the name would no longer be accurate. Ideally, we would rename the lint when generalizing it. ↩