Refactor and Improve Versioning Mechanism

[davidvonthenen]

This PR has the following changes:

• restructure the project to separate the v1_ from the individual files, creates a directory called v1 and moves the files in them. Example of a single file looks like: live/v1_client.py -> live/v1/client.py
  • The cool side effect is that to implement a v2, the files can have consistent file names (ie client for v1 and v2 can be in client.py in their respective folders. This mimics versioning in the Go SDK but in the Python way since the language isn't strongly typed.
  • all classes V1 at the end, has been renamed Latest. This basically points to which is Latest version of the API that is supported.
• Refactored the API versioning so that it's more dynamic. This enables it so we don't need to modify code specifically in the deepgram/client.py and deepgram/clients/client.py classes. There is a parameter to pass in the version when doing the instantiations of classes. See example below.
  • This enables us to handle multiple versions, along with alpha, beta, RC versions, and even breaking API that we want to preserve the backwards compatibility on

This effectively queries v1/projects on the API to list available projects:

# get projects
projectResp = await deepgram.manage.v("1").get_projects()
if projectResp is None:
  print(f"ListProjects failed.")

When a v2 is available, you will be able to call the following:

# gets v2 of the API
projectResp = await deepgram.manage.v("2").get_projects()

# gets v1 of the API
projectResp = await deepgram.manage.v("1").get_projects()

# gets the most recent API version (which is v2)
projectResp = await deepgram.manage.latest.get_projects()