nipanel: Delete _typing submodule and use typing_extensions directly

[bkeryan]

What does this Pull Request accomplish?

Add a dependency on the typing-extensions package and import symbols directly from typing_extensions.

I did the same for nitypes in ni/nitypes-python#21

Why should this Pull Request be merged?

Single-sourcing typing_extensions imports in a private _typing submodule is not working well. I'm starting to think that avoiding typing_extensions at run time is not worth it. It is lightweight and has no external dependencies.

With a private _typing submodule, sphinx-autoapi renders type aliases as nitypes._typing.TypeAlias. If we use typing.TypeAlias directly, it renders them as a PEP 695 type statement showing what they are aliased to. I have proposed updating sphinx-autoapi to do the same for typing_extensions.TypeAlias: readthedocs/sphinx-autoapi#521

This pattern works for sphinx-autoapi, but not for mypy, due to python/mypy#14220

try:
    from typing import TypeAlias
except ImportError:
    from typing_extensions import TypeAlias  # or from nitypes._typing

What testing has been done?

Ran nps, mypy, pytest.

[github-actions]

Test Results

10 files  ±0  10 suites  ±0   8s ⏱️ +3s
 6 tests ±0   6 ✅ ±0  0 💤 ±0  0 ❌ ±0 
60 runs  ±0  60 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit d5cc5a5. ± Comparison against base commit ed3320d.

♻️ This comment has been updated with latest results.

[jfriedri-ni]

The submodule is not deleted yet in this PR. Does it need to be removed in a follow-up to satisfy another constraint?

[bkeryan]

The submodule is not deleted yet in this PR. Does it need to be removed in a follow-up to satisfy another constraint?

Oops, that was a mistake. It's deleted now.