Deprecate API interface, expose underlying "Teams" client

[atc0005]

Overview

As mentioned in GH-149:

Next steps

A real challenge in the current package design is that it exposes the API interface instead of a concrete type. In order to expose the functionality added by #134 and #135, we'll need to expose the "client" (renaming teamsClient to TeamsClient) or provide a new variation of the API interface (e.g., APIv2).

and on https://go.dev/blog/module-compatibility:

Sometimes, new features require changes to publicly-exposed interfaces: for example, an interface needs to be extended with new methods. Directly adding to an interface is a breaking change, though—how, then, can we support new methods on a publicly-exposed interface?

The basic idea is to define a new interface with the new method, and then wherever the old interface is used, dynamically check whether the provided type is the older type or the newer type.

Overall, I feel the current API interface is too limiting. Based on the module compatibility guidelines, any new functionality that we add constitutes a breaking change. While doable, it doesn't seem like bumping a major version in order to add a minor change is really feasible. Instead, I plan to expose the underlying client in an effort to grow functionality and still maintain backwards compatibility with existing client code.

Goals

• deprecate the current API interface
• expose TeamsClient to take its place
• create common interfaces and helper code to abstract specific Microsoft Teams message formats
• update examples to reflect changes
• restore support for overriding default http.Client
• restore default project-specific user agent, support for overriding the default from client code
• create "subpackages" to group functionality for specific message formats