This is needed to track anon const parents properly once we implement
`ConstArgKind::Path` (which requires moving anon const def-creation
outside of `DefCollector`):

    Why do we need this in addition to [`Self::current_hir_id_owner`]?

    Currently (as of June 2024), anonymous constants are not HIR owners;
    however, they do get their own DefIds. Some of these DefIds have to be
    created during AST lowering, rather than def collection, because we
    can't tell until after name resolution whether an anonymous constant
    will end up instead being a [`rustc_hir::ConstArgKind::Path`]. However,
    to compute which generics are available to an anonymous constant nested
    inside another, we need to make sure that the parent is recorded as the
    parent anon const, not the enclosing item. So we need to track parent
    defs differently from HIR owners, since they will be finer-grained in
    the case of anon consts.

This will allow lowering const params to a dedicated enum variant, rather
than to an `AnonConst` that is later examined during `ty` lowering.

Now everything that actually affects the type system (i.e., excluding
const blocks, enum variant discriminants, etc.) *should* be using
`ConstArg`.

This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:

- `ConstArgKind` gets a new `Path` variant, and all const params are now
  represented using it. Non-param paths still use `ConstArgKind::Anon`
  to prevent this change from getting too large, but they will soon use
  the `Path` variant too.

- `ConstArg` gets a distinct `hir_id` field and its own variant in
  `hir::Node`. This affected many parts of the compiler that expected
  the parent of an `AnonConst` to be the containing context (e.g., an
  array repeat expression). They have been changed to check the
  "grandparent" where necessary.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at rust-lang#127009.

Co-authored-by: Boxy <rust@boxyuwu.dev>