Introduces Linting (pylint) and Static Checking (mypy) for the SDK

[davidvonthenen]

Proposed changes

Implements: #390

This PR is pretty large, to say the least, because it introduces linting (using pylint) and static checking (using mypy - previously, I was going to use pyright). To introduce linting and static checking for PRs, you need to fix all of the issues that it flags. This happened to be a lot issues because during the development of v3 of this SDK, style (aka linting) and certain type checks (aka mypy) was lacking intentionally in order to meet the timeline for release. Since python is pretty forgiving in the type check department, we deferred that until now.

The user can test their compliance with pylint and mypy locally by invoking the same process used in the GitHub actions as follows:

• make lint
• make static

GitHub actions run for this PR:

• lint check: https://github.com/deepgram/deepgram-python-sdk/actions/runs/9450572426/job/26029481172?pr=411
• static check: https://github.com/deepgram/deepgram-python-sdk/actions/runs/9450572427/job/26029481196?pr=411

Other notable changes:

• this introduces 2 new GitHub actions to check for pylint and mypy issues for new PRs and on main
• observes python best practices to use _ for class scoping
• (THIS HAPPENED TO BE A LARGE PART OF THE CHANGES IN THIS PR) had to change @dataclass_json annotations (now just extends the DataClassJsonMixin class in dataclass_json because the project doesn't implement a pylint plugin for linting
• for all the Latest classes, these just needed to be alias definitions instead of extending the class since the linter through that was better (agreed because we weren't introducing any new variables, functions, etc)

NOTES:

• These changes should NOT be breaking changes.
• Ran all examples in order to verify nothing, in fact, has changed.
• Will refactor a little in a subsequent PR for functions that duplicate a lot of code. Currently, there are some disable pylint and mypy checks for certain functions to make sure the functionality/behavior of the SDK doesn't change.

Types of changes

What types of changes does your code introduce to the community Python SDK?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update or tests (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have lint'ed all of my code using repo standards
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

NA