Fix use of mypy while maintaining pyright compatibility

[adamtheturtle]

In #72 I fixed pyright use but broke pyright. The long term fix is probably to have mypy and pyright run against src/ and tests/ in CI.

In the short term I have tested this against my own repository (https://github.com/adamtheturtle/sphinx-notionbuilder).

The underlying issue is that mypy treats Decorator = Callable[[F], F] differently to how pyright does. mypy doesn't like parameterized type aliases while pyright required that the type alias was parameterized.

[espdev]

Actually, I still get mypy errors if I just run mypy -p click_option_group.

src\click_option_group\_helpers.py:25: error: Incompatible return value type (got "Tuple[Any, List[Parameter]]", expected "Tuple[Callable[..., Any], List[Option]]")  [return-value]
src\click_option_group\_helpers.py:33: error: List item 0 has incompatible type "Optional[str]"; expected "str"  [list-item]
src\click_option_group\_core.py:133: error: Need type annotation for "_group_title_options"  [var-annotated]
src\click_option_group\_core.py:216: error: Value of type variable "F" of "resolve_wrappers" cannot be "Optional[Callable[..., Any]]"  [type-var]
src\click_option_group\_decorators.py:138: error: "remove" of "list" does not return a value (it only ever returns None)  [func-returns-value]
Found 5 errors in 3 files (checked 5 source files)

I think we need to review all types and fix mypy issues.

[adamtheturtle]

I submitted this to fix type issues I have as a user.

See https://github.com/click-contrib/click-option-group/compare/master...adamtheturtle:click-option-group:fix-mypy?expand=1 for a start of getting mypy actually passing on this project.

[espdev]

Yes, I understand. I will try to resolve the remaining mypy issues and add type checking to CI.