Checker: report environment before checking namespace

[auduchinok]

A follow up for #18519.

It turns out features like the code completion relied on the own environment being reported when checking top level declarations in some cases. This is not an entirely correct approach, but it's likely that there are many similar places where things assumed something close enough being reported.

#18519 has broken cases where a name resolution environment just before checking a namespace was lost (i.e. including previously checked namespaces). This PR adds reporting the environment before checking the current namespace fragment. This may break some other things but it seems it's a step in the right direction.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md

[auduchinok]

It turns out the same captured environments are used in different kinds of features, even though their requirements are different:

• code completion requires an environment captured before the symbol checking, i.e. it should include previously checked symbols but it should not be able to resolve a symbol name inside its declaration (unless it's recursive)
• tooltips may require an environment that was captured after the checking, so it would be possible to resolve a symbol when hovering its declaration with a mouse

These requirements contradict each other. Previously we ignored some of the related small bugs here and there, and #18519 was an attempt at fixing some of them.

What can be done here is one these options:

• optionally mark the captured environments as pre/post-check and add additional checks when getting environments
  • provides some control to the features
• capture additional environments at the ranges of the symbol declaration names
  • this is already done for some declarations (e.g. for local values), but not consistently
  • code completion is normally unavailable at these ranges
• revert Checker: don't capture environment for checked modules #18519 (i.e. report the post-check env again), keep this PR and modify the pre-check env ranges, so they don't capture the name part
  • this is a trade-off that could seemingly allow using pre-check envs in code completion and would fallback to the post-check ones at the name ranges
  • requires calculating body ranges

It's likely that all of these approaches will require fixing features that (accidentally) rely on the current behavior. It may also turn out to be more work to do it consistently across different kinds of declarations.

[auduchinok]

There's another interesting detail. Features like tooltips try to get previously reported symbols at the given range first, so sticking with environments tailored for code completion may be a good (and simple!) approach after all.

The reason some of the FCS tests fail is they provide incorrect arguments like the line text or coordinates, which happened to work with the previous implementation (which seems incorrect).
Updating the arguments in these tests fixes them. I've reused the same {caret} approach as in the code completion tests, so it's now easier to provide the correct data in these tests. We should use it in more places, it makes it much better.

Let's see what does CI say for the rest of the tests.

[auduchinok]

Yay, it's green 🙂

[T-Gro]

Thanks @auduchinok for the detailed analysis and targeted fix here!