fix(typing): improve view type inference of ui decorators

[shiftinv]

Summary

This adjusts some internal typings to get rid of Unknowns in button/select decorators.

• view_cls.method now has a properly typed (Self@V, Item[Self@V], MsgInter) signature, instead of (Any, Unknown, MsgInter)
• more importantly, self.method now returns an Item[Self@V] with the correctly bound view type, instead of Item[V_co], which was unbound and didn't allow accessing custom attributes on self.method.view

class CustomView(disnake.ui.View):
    x: int

    @disnake.ui.string_select(options=["A", "B"])
    async def sel(self, s, i):
        # before: StringSelect[V_co@string_select]  # <<< note, view type unbound
        # after: StringSelect[Self@CustomView]
        reveal_type(self.sel)

        # before: (Any, Unknown, MessageInteraction[Unknown]) -> Coroutine[Any, Any, Any]
        # after: (CustomView, StringSelect[Self@CustomView], MessageInteraction[Unknown]) -> Coroutine[Any, Any, Any]
        reveal_type(type(self).sel)

        # before: [error]
        # after: int
        reveal_type(self.sel.view.x)

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• This PR adds something new (e.g. new method or parameters)
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[Enegg]

I suggest we replace this Protocol with simply Callable[P, T_co]; I didn't realize at the time that Callable fulfills the criteria for capturing init args and return type :)

[shiftinv]

Right, I suppose that works too; it would widen the possible input types though, since it allows arbitrary callables and isn't necessarily limited to types. Something like Callable[P, T_co] & Type[T_co] would be cool, if we had intersection types.

[Enegg]

it would widen the possible input types

I'm aware, however I don't see a reason to restrictict the accepted types. The runtime already supports that if not for the issubclass checks, this would work out of the box.