fix: correctly handle unions in verify_type

[shiftinv]

Summary

Fixes #577.

An annotation like Union[User, Member] passes the issubclass_(self.type, disnake.Member) check since issubclass_ explicitly handles unions; the following isinstance(argument, disnake.Member) check did not accept User objects, even though they should've been permitted based on the annotation type.
This PR improves the validation logic to correctly handle cases like this as well.

Regression from #283 - third test case of test_verify_type checks for this particular one.

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 task lint
  • I have type-checked the code by running task 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, ...)

[onerandomusername]

This still has a minor bug with users and members:

    @parent.sub_command("user")
    async def user(self, itr: disnake.CommandInteraction, user: disnake.User):
        await itr.send(type(user))

[shiftinv]

This still has a minor bug with users and members

it's not a bug, it's a feature
But yeah, that seems to be working as intended, even if Member doesn't inherit from User it ends up having the same attributes+methods due to @flatten_user

[onerandomusername]

Sounds good, then.