Rollup merge of #158617 - khyperia:gca-syntax-flip, r=BoxyUwU

allow mGCA const arguments to fall back to anon consts

makes good progress on https://github.com/rust-lang/project-const-generics/issues/108

`min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?"

Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context)

on **stable**, the full list of things can be directly represented is (... it's just the one thing)

- paths to generic const parameters

on `main`, under mGCA, **before** this PR:

- absolutely everything, if something cannot be represented directly, compiler error
- `const { }` gives you an escape hatch to go back to being an anon const

on macro**ful** gca, the directly represented things will be:

- paths to const parameters
- `direct_const_arg!` macro

on macro**less** gca, the directly represented things will be:

- paths to const parameters
- `direct_const_arg!` macro (not *particularly* useful under macro**less** gca)
- struct expressions, arrays, blah blah
- currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...)

this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca

Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above).

r? @BoxyUwU