Add support for type hierarchy requests

[Morriar]

Closes #1046.

Implement support for:

• textDocument/prepareTypeHierarchy: https://microsoft.github.io/language-server-protocol/specification#textDocument_prepareTypeHierarchy
• typeHierarchy/supertypes: https://microsoft.github.io/language-server-protocol/specification#typeHierarchy_supertypes
• add stub support for typeHierarchy/subtypes as we do not have the necessary logic in the index yet

Demo:

[vinistock]

Needs a rebase, but this looks good to me.

We should also add the typeHierarchy configuration and its respective default here so that it's enabled.

[vinistock]

Looks good. For whatever reason, switching between sub and super types multiple times on certain namespaces causes an error in the extension side Cannot read properties of undefined (reading 'map').

You can reproduce it in the core_ext/uri file. It succeeds initially, but switching back and forth eventually fails.

I'm not sure if this isn't because of the lack of sub types implementation, so maybe we can move forward and debug that after sub types?

[st0012]

I think the 2 gifs are exactly the same?

[Morriar]

Looks good. For whatever reason, switching between sub and super types multiple times on certain namespaces causes an error in the extension side Cannot read properties of undefined (reading 'map').

Good find, I can investigate 👍

[Morriar]

I think the 2 gifs are exactly the same?

They are, the prepareTypeHierarchy doesn't do much, it just prepares the field for the supertypes / subtypes requests.

The issue is that we test for each request to have a gif and for the gif to be the same name than the request. I guess I could use a symlink though?

[Morriar]

I updated the PR to changes two behaviors:

1. Always return only one item in the prepareTypeHierarchy response to avoid a VSCode crash while we investigate what should be the expected behavior
2. Only return the first level of direct ancestors rather than the fully linearized list while we decide what is the best DX

[st0012]

🚀

[st0012]

Not related to this PR, but I think we can make determine_target simply take a NodeContext because all of its usages take node and parent from the same context.