This PR fixes spurious results in path resolution that could cause blowup in type inference.

The path resolution problem

For a trait or an impl block its type parameters and associated types are both successors of the block's item node. This causes them to get mixed up as seen in this example:

trait Foo<Bar> {
  type Bar;
  fn foo(&self) -> Bar; // <- Resolves to both the type parameter and the associated type
  fn bar(&self) -> Self::Bar; // <- Resolves to both the type parameter and the associated type
}

The Bar in the return type of foo should resolve to the type parameter and the Self::Bar in the return type of bar should resolve to the associated type. But path resolution doesn't distinguish them causing them to get mixed up.

The effect on type inference

Here is an example of how this causes problems for type inference:

impl<Output> TraitWithAssocType for GenS<Output> {o
    type Output = Result<Output, Output>;
    //                   ^       ^
    //                   Resolves to both the type parameter and the associated type
    // ...
}

Here the Output type is interpreted correctly, but also incorrectly as if the type is recursive and the Output on the rhs. is a self reference. This causes its type to be all of the below:

• Result<Output, Output>
• Result<Result<Output, Output>, Result<Output, Output>>
• Result<Result<Result<Output, Output>, Result<Output, Output>>, Result<Result<Output, Output>, Result<Output, Output>>>
• ... and so on exponentially.
  This puts type inference in an exponential "infinite" loop that gets cut off when we reach the maximum path length.

I believe the performance problems we saw with tuple types is because the databend project contains a case like the above but where the rhs. is a tuple and a macro is generating instances for all tuples from arity 1 up to arity 2. This leads to (in addition other things) a type mention with 12^10 paths under it (10 is the max path limit). Hence this PR should also unblock tuple type inference.

DCA

We get a little above a 0.2% point increase in resolved calls and analysis time drops by 1.4%. Path resolution inconsistencies wobble a bit but overall decreases.

Some thoughts on the fix

(These are just some thoughts, maybe for the future, that can be ignored for initial review)

I struggled a bit to fix this in path resolution and the first two approached I tried didn't pan out.

The way I think of it now, the successor relation in the item graph kinda conflates two different things:
1/ the items that are available locally in the scope of an item
2/ the items that are available externally for qualified paths that resolve to the item.

For instance for the trait example

trait Foo<Bar1> {
  type Bar2;
  // ...
}

Bar1 is something that's available locally in the trait block (a Bar1 path inside it can refer to it, but it's not available outside through a Foo::Bar1 path). On the other hand Bar2 is available externally (a Foo::Bar2 path can refer to it but a Bar2 path inside it as is invalid). Most of the time this conflation evidently works perfectly fine, but in this specific case name overlap caused problems.

I wonder if a design that separated the two things would be cleaner? Perhaps to different member predicates on ItemNode or different classes altogether? I'm not really sure though and @hvitved may have some thoughts on whether that would or wouldn't work. Instead this PR just introduces two predicates that can be used to exclude certain getAChildSuccessor edges for the local or external case.