Version 2.0.0: Refactor PagerDuty into a multi-file module

[Deconstrained]

Context

This pull request addresses #27.

Summary

Multi-file Refactor

It includes significant structural changes to the pagerduty package by refactoring what was a monolithic python module file into a multi-file module in the pagerduty directory.

For backwards compatibility, all helper methods and classes are imported to the root namespace of the module (in __init__.py). Any new API client classes (i.e. for the newer integration product APIs) are expected to be added in aptly-named files and similarly imported to the root of the module. Classes are expected to be usable as they always previously have. For example:

# Valid, preferred
client = pagerduty.RestApiV2Client(API_KEY)

# Also now valid, but should not be necessary:
client = pagerduty.rest_api_v2_client.RestApiV2Client(API_KEY)

Going forward, any specialized helpers that are declared only in the module where they are used are not necessary to import into the root module namespace (or add to sphinx/source/module_reference.rst for that matter) unless the intention is to publish them for use outside their original purpose. All methods should still have docstrings regardless.

Minor changes

• Update docstring and type hint in EventsApiV2Client.send_change_event. The return statement was removed in 1.0.0 because it is expected to always be None based on the schema, and Python functions without a return statement effectively return None, but the docstring and type hint were not updated. This caused an issue with Airflow CI/CD builds (see Fix: add missing Return event ID from change event submission #38).
• Change the prefix of the user-agent header from pagerduty to python-pagerduty

Before Releasing

• Perform a test publish / install to validate that upgrading from 1.0.0 works
• Integration test the module as a reality check