Fix ICE: When Trying to check visibility of a #[type_const], check RHS instead.
This PR fixes https://github.com/rust-lang/rust/issues/150956 for min_const_generic_args https://github.com/rust-lang/rust/issues/132980.
The first part of this PR checks in `reachable.rs` if we have a type const use `visit_const_item_rhs(init);` instead of calling `const_eval_poly_to_alloc()`
The second part is I noticed that if `const_eval_poly_to_alloc()` returns a `ErrorHandled::TooGeneric` then switches to `visit_const_item_rhs()`. So further up `const_eval_poly_to_alloc()` call order it eventual gets to `eval_in_interpreter()`. So I added a debug_assert in `eval_in_interpreter()` if we happen to try and run CTFE on a `type_const`.
The other bit is just a test case, and some duplicated code I noticed.
While the PR does get rid of the ICE for a type_const with `pub` visibility. If I try using the const though it will ICE with the following:
```
error: internal compiler error: /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13: expected ConstKind::Param or ConstKind::Value here, found UnevaluatedConst { def: DefId(20:4 ~ colorkit[c783]::TYPE_CONST), args: [] }
thread 'rustc' (819687) panicked at /home/keith/GitHub/rust_kc/compiler/rustc_const_eval/src/check_consts/qualifs.rs:355:13:
```
I suspect it is a similar issue to inherent associated consts. Since if I apply the same fix I had here:
https://github.com/rust-lang/rust/pull/150799#discussion_r2676504639
I then can use the const internally and in external crates without any issues.
Although, did not include that fix since if it is a similar issue it would need to be addressed elsewhere.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
9f6cd6defb