Fix PoI + forwarding candidate order

[DanilaFe]

Closes #28246 by untangling forwarding from POI.
Closes #28354 by making speculatively resolved calls still count for POI caching.

Consider the program from that issue:

module A {
  record Inner {
    proc foo() {
      return 42;
    }
  }
}

module B {
  import A.Inner;

  record Outer {
    forwarding var inner: Inner;
  }
}

module C {
  import B.Outer;

  record Outermost {
    forwarding var outer: Outer;
  }
}

module D {
  import A.Inner;
  import B.Outer;
  import C.Outermost;

  proc generic(x) {
    writeln(x.foo());
  }

  proc case1() {
    generic(new Outermost());
  }

  proc case2() {
    proc Outer.foo() do return "Outer foo";
    generic(new Outermost());
  }

  proc case3() {
    generic(new Outermost());
  }

  proc main() {
    case1();
    case2();
    case3();
  }
}

While previously, forwarding and POI would be interleaved as follows:

Old Ordering:

• non-POI candidates for Outermost.
• POI candidates for Outermost.
• non-POI candidates for Outer.
• POI candidates for Outer.
• non-POI candidates for Inner
• POI candidates for Inner.

After this PR, they will be interleaved as follows:
New Ordering:

• non-POI candidates for Outermost.
• non-POI candidates for Outer.
• non-POI candidates for Inner
• POI candidates for Outermost.
• POI candidates for Outer.
• POI candidates for Inner.

This ensures that user code cannot "hijack" library procedures by defining POI overloads for types like Outermost, where previously the type forwarded this method from Inner. It also ensures that POI scopes are attempted only if the call would not have otherwise resolved, since this is required for caching instantiations.

There are effectively 4 phases to the new resolution strategy:

Phase	Candidates considered
Phase 1	Non-POI candidates for Outermost (`searchOnePoiLevel
Phase 2	(Transitive) Non-POI candidates forwarded by Outermost (resolveForwardedCall(considerPOI=false))
Phase 3	POI candidates for Outermost (findVisibleFunctionsAndCandidates)
Phase 2	(Transitive) POI candidates forwarded by Outermost (resolveForwardedCall(considerPOI=true))

When implementing this, I noticed that we had several functions that threaded through much state. These functions had to be split and interleaved with forwarding handling, which would've required more state to be lifted to the top-level resolveNormalCall function and threaded through. Instead of doing so, I consolidated all the shared state into a new struct, CandidateSearchState. I also tried to improve the comments in the affected code, since I found it somewhat difficult to follow at first.

The implementation details are as follows. Since resolveForwardedCall can recurse (implementing the step from Outer to Inner above, allowing for transitive forwards), which it does by calling resolveNormalCall, and since in phase 2 it is too early to consult POIs, I needed to adjust resolveNormalCall to enable it to ignore POI when needed. Furthermore, since we did want a POI candidate search for forwards eventually (phase 4), I also needed to allow resolveForwardedCall to request POI candidates after all. This led to me threading through considerPoi boolean arguments to both of these functions.