Feature/typehint hardening

[SecondeJK]

While this PR might look a bit big, it's just a cleanup to harden the code. This is a review of the codebase where Typehints can be introduced.

Description

Typehints with nullsafe settings have been introduced wherever they can. While it could be regarded as a SemVer backwards breaking change, it technically is not. This is because the only way you could be calling the existing methods or properties that are not typehinted is through passing in wrong types which would result in an exception anyway.

The exception to the review is the SMS Client, which is used by Laravel and therefore will only be updated with the next major version of the SDK.

Motivation and Context

Harden API to add standards

How Has This Been Tested?

The test library has been key to this in that it has been run with each iteration of the code changes.

Types of changes

• Bug fix (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 change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.