Help us narrow down Tina's API surface area

[jeffsee55]

Tina has gone through a few iterations over the past couple of years, and while we're happy with where things currently are, there are a lot of older modules that we're still maintaining for backwards compatibility. As Tina has grown, boilerplate needed to get everything working has shrunken signifcantly. This was an intentional process, and we've continued to export many internal modules that we don't intend to be used as part of the future public API, even though some of them may still work.

In an effort to move things forward we'd like to deprecate many of the older modules and provide a much smaller surface area for what is exported from the tinacms package. While many of these modules still work in a technical sense - there shouldn't be a need for them (and if there is, we'd love to know!)

I'm proposing that we restrict exports from the tinacms module to what we consider to be part of our "happy path", and re-export the rest from another folder (eg. tinacms/legacy). The main import would still include our core functions like defineConfig, defineSchema, and React components like TextField, wrapFieldsWithMeta, and other field-level APIs. That way, we can agressively remove modules that we don't expect anyone to be using, and if they are using them, they just need to change their import to import { FormPortal } from 'tinacms/legacy' (for example).

If this matters to you please let us know what you would prefer, or make a comment about how you are customizing Tina, and any APIs that you are relying on. Our hope is that we can provide better Typescript types across the board, and document more advanced customization use-cases once we know a bit more about how Tina is being used.