[WIP] Improve STACObject inheritance

[duckontheweb]

Related Issue(s): #

• Casting root Catalog to Catalog type interferes with pystac-client Client class #410

Description:

Based on #410 and conversation with @matthewhanson, this is a start on some work to:

1. Allow developers to create their own sub-classes of Item, Collection, and Catalog and have the classmethods return the expected sub-classes (see this Catalog test for an example use-case).

2. Decouple migration from serialization (or at least make it more explicit and transparent)

3. Simplify some of the interplay between the stac_io, STACObject, and the serialization module.

I haven't made as much headway on the 3rd point, but I'm interested in feedback on the approach so far.

This also updates the deprecation notice for STAC_IO. If this PR ends up needing more time I can break that off into a separate PR so we can get it into the next pre-release.

cc: @matthewhanson @lossyrob

PR Checklist:

• Code is formatted (run scripts/format)
• Tests pass (run scripts/test)
• This PR maintains or improves overall codebase code coverage.
• Changes are added to the CHANGELOG. See the docs for information about adding to the changelog.

[duckontheweb]

Factored out the STAC_IO deprecation warnings to a separate PR so we could integrate those separately.

I will rework this PR to separate out fixing the inheritance from decoupling migration/serialization so it's easier to comment on those separately.

[duckontheweb]

@matthewhanson @lossyrob I removed the logic that decoupled migration from serialization in #451 (which supersedes this PR) so we can focus on just the inheritance piece.