Support const args in type dependent paths

[lcnr]

#![feature(const_generics)]

struct A;
impl A {
    fn foo<const N: usize>(&self) -> usize { N }
}
struct B;
impl B {
    fn foo<const N: usize>(&self) -> usize { 42 }
}

fn main() {
    let a = A;
    a.foo::<7>();
}

When calling type_of for generic const arguments, we now use the TypeckTables of the surrounding body to get the expected type.

This alone causes cycle errors though, as we now have typeck_tables_of(main) -> ... ->
type_of(main_ANON0 := 7) -> typeck_tables_of(main) ⚡ (see #68400 (comment))

To prevent this we must not call type_of(const_arg) during typeck_tables_of. This is achieved by
calling type_of(param_def_id) instead. As this DefId can't always be easily known, I changed some DefIds to ty::WithOptParam<DefId> which contains the relevant param id. This also changes some queries which may be called during typeck.

To prevent us from computing these queries twice, WithOptParam must always use the correct
DefId of the parameter. This means that it is either constructed using the new method tcx.with_opt_param(def_id) or manually if and only if a param DefId is available.

To simplify WithOptParam creation, I changed IntoQueryParam from private to pub(crate).
I only use the existing definition of LocalDefId -> DefId.

const_param_of requires the HIR, meaning that it can only return the correct parameter DefId while compiling the crate containing the const argument.

To fix this, const_param_of is called for all const arguments during analysis. (I currently use par_body_owner here, as all const arguments should be a body afaik)

This PR may have missed some type_of(const_arg) during typeck. While this is unfortunate, these cases should only introduce cycle errors and not lead to miscompilations.
We should not have to worry about these cases while merging this IMO.

r? @varkor
fixes #70507, fixes #69816, fixes #63695, fixes #61936, fixes #71516