Examine JSON DataClasses and Remove Optional for Those That are Required

[davidvonthenen]

Proposed changes

Addresses issue: #310

IMPORTANT: This builds on top of this PR: #314 and #316. Do not merge until those PRs are merged.

For a cleaner diff between this PR and its dependency #316, please look at this compare for convenience:
https://github.com/dvonthenen/deepgram-python-sdk/compare/audit-legacy-v2-syntax...dvonthenen:deepgram-python-sdk:remove-optional-dataclass

IMPORTANT IMPLEMENTATION DETAIL TO REVIEWER/USER: Any parameter on any class that is present when a feature is enabled/disabled, but is missing when a different feature is enabled/disabled, MUST be marked Optional and will be omitted from the JSON (that's the field/lambda function stuff you see in the code).

If the removal of property isn't done, this is the undesired JSON output that is currently happening:

{
    "alternatives": null,
    "callback": null,
    "callback_method": null,
    "custom_intent": null,
    "custom_intent_mode": null,
    "custom_topics": null,
    "custom_topic_mode": null,
    "detect_entities": null,
    "detect_language": null,
    "detect_topics": null,
    "diarize": null,
    "diarize_version": null,
    "dictation": null,
    "extra": null,
    "filler_words": null,
    "intents": null,
    "keywords": null,
    "language": null,
    "measurements": null,
    "model": "nova-2",
    "multichannel": null,
    "numerals": null,
    "paragraphs": null,
    "profanity_filter": null,
    "punctuate": null,
    "redact": null,
    "replace": null,
    "search": null,
    "sentiment": null,
    "smart_format": true,
    "summarize": null,
    "tag": null,
    "tier": null,
    "topics": null,
    "utt_split": null,
    "utterances": null,
    "version": null
}

Making the fields optional as in this PR, yields the following:

{
    "model": "nova-2",
    "smart_format": true
}

Notable changes in this PR:

• All properties in Option classes (i.e., the Input options for PreRecorded or Live, for example) are optional since they are only set when needed. Please see above.
• If an object itself is Optional, but when the object is present it's properties are required, those properties will be required when looking at the class definition in code. Just explicitly calling this out in order to avoid confusion.

Exercised each of the examples and made sure the expected values were there.

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

The merge-base changed after approval.

The merge-base changed after approval.