Add go-to-definition inference for shadowed namespaces

[PierceLanternStudios]

Written as a proposed solution to #55593.

Note that like 95% of the changes for this PR come from updating test baselines, since my solution involves the use of a timeout inside the session.

Solves the issue of namespace shadowing by checking for "typey" definitions in comparison with the kind of the node selected. If its not possible to narrow to one definition, defaults to the current behavior of showing all options. Additionally, if the same symbol is go-to-definitioned on twice within 5 seconds, this will show all definitions as a backoff system.

Tested locally + with hereby runtests

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[typescript-bot]

Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.

Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up.

[PierceLanternStudios]

@microsoft-github-policy-service agree

[rattrayalex]

Hey @DanielRosenwasser & Ryan, curious for your thoughts here! I think it'd make a huge difference for devs using the Stripe, OpenAI, Anthropic, and similar SDKs, which make heavy use of a namespace/interface shadowing pattern for easy type imports.

[jakebailey]

I don't think the way this change works is tenable; we shouldn't be changing the behavior based on some sort of delay depending on how quickly the user does something. These calls should all be idempotent. Anything else is going to be hard to test and hard port over to Go when the time comes.

Can you by chance try our new language server to see if the same thing happens there? https://marketplace.visualstudio.com/items?itemName=TypeScriptTeam.native-preview

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate