[red-knot] Add Type.definition method

[MichaReiser]

Summary

This is a follow up to the goto type definition PR. Specifically, that we want to avoid exposing too many semantic model internals publicly.

I want to get some feedback on the approach taken. I think it goes into the right direction but I'm not super happy with it.
The basic idea is that we add a Type::definition method which does the "goto type definition". The parts that I think make it awkward:

• We can't directly return Definition because we don't create a Definition for modules (but we could?). Although I think it makes sense to possibly have a more public wrapper type anyway?
• It doesn't handle unions and intersections. Mainly because not all elements in an intersection may have a definition and we only want to show a navigation target for intersections if there's only a single positive element (besides maybe Unknown).

An alternative design or an addition to this design is to introduce a SemanticAnalysis(Db) struct that has methods like type_definition(&self, type) which explicitly exposes the methods we want. I don't feel comfortable design this API yet because it's unclear how fine granular it has to be (and if it is very fine granular, directly using Type might be better after all)

Test Plan

cargo test

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[carljm]

This seems fine to me, and I'm happy to see a lot of unnecessary pub removed.

I think of Definition as a pretty internal implementation detail of the semantic index and symbol resolution, so I'd prefer if it weren't pub at all, and I'm happy to have a separate TypeDefinition struct exposed as public API.

I don't think it would make sense to have Definition for a module, because the meaning of Definition is a value assigned to a name in a scope, which doesn't apply to an entire module.

Leaving the caller to decide how to handle intersections and unions also seems reasonable to me; the union or intersection type does not itself have a definition location. I guess the main disadvantage I see here is that it requires us to expose more of the API of union and intersection types, but we probably will need this for the linter anyway.