This introduces `GotoTarget::Call` that represents the kind of
ambiguous/overloaded click of a callable-being-called:

```py
x = mymodule.MyClass(1, 2)
             ^^^^^^^
```

This is equivalent to `GotoTarget::Expression` for the same span but
enriched
with information about the actual callable implementation.

That is, if you click on `MyClass` in `MyClass()` it is *both* a
reference to the class and to the initializer of the class. Therefore
it would be ideal for goto-* and docstrings to be some intelligent
merging of both the class and the initializer.

In particular the callable-implementation (initializer) is prioritized
over the callable-itself (class) so when showing docstrings we will
preferentially show the docs of the initializer if it exists, and then
fallback to the docs of the class.

For goto-definition/goto-declaration we will yield both the class and
the initializer, requiring you to pick which you want (this is perhaps
needlessly pedantic but...).

Fixes astral-sh/ty#898
Fixes astral-sh/ty#1010

This introduces `GotoTarget::Call` that represents the kind of
ambiguous/overloaded click of a callable-being-called:

```py
x = mymodule.MyClass(1, 2)
             ^^^^^^^
```

This is equivalent to `GotoTarget::Expression` for the same span but
enriched
with information about the actual callable implementation.

That is, if you click on `MyClass` in `MyClass()` it is *both* a
reference to the class and to the initializer of the class. Therefore
it would be ideal for goto-* and docstrings to be some intelligent
merging of both the class and the initializer.

In particular the callable-implementation (initializer) is prioritized
over the callable-itself (class) so when showing docstrings we will
preferentially show the docs of the initializer if it exists, and then
fallback to the docs of the class.

For goto-definition/goto-declaration we will yield both the class and
the initializer, requiring you to pick which you want (this is perhaps
needlessly pedantic but...).

Fixes astral-sh/ty#898
Fixes astral-sh/ty#1010

…inition

Previously, we would include the class definition in addition to the
`__init__` and `__new__` methods, if present. But it seems that this
generally leads to unintuitive behavior from the perspective of users.
It's also not what pyright does.

This was also discussed a bit in the PR adding this functionality:
#20014.

Fixes astral-sh/ty#2218, Ref astral-sh/ty#2639

…inition

Previously, we would include the class definition in addition to the
`__init__` and `__new__` methods, if present. But it seems that this
generally leads to unintuitive behavior from the perspective of users.
It's also not what pyright does.

This was also discussed a bit in the PR adding this functionality:
#20014.

Fixes astral-sh/ty#2218, Ref astral-sh/ty#2639

…inition

Previously, we would include the class definition in addition to the
`__init__` and `__new__` methods, if present. But it seems that this
generally leads to unintuitive behavior from the perspective of users.
It's also not what pyright does.

This was also discussed a bit in the PR adding this functionality:
#20014.

Fixes astral-sh/ty#2218, Ref astral-sh/ty#2639

…inition

Previously, we would include the class definition in addition to the
`__init__` and `__new__` methods, if present. But it seems that this
generally leads to unintuitive behavior from the perspective of users.
It's also not what pyright does.

This was also discussed a bit in the PR adding this functionality:
#20014.

Fixes astral-sh/ty#2218, Ref astral-sh/ty#2639

…inition

Previously, we would include the class definition in addition to the
`__init__` and `__new__` methods, if present. But it seems that this
generally leads to unintuitive behavior from the perspective of users.
It's also not what pyright does.

This was also discussed a bit in the PR adding this functionality:
#20014.

Fixes astral-sh/ty#2218, Ref astral-sh/ty#2639