Spike: Explore adding configuration options to the tree item formatter to support alternate use-cases

In order to meet this use-case it would be simple enough to expand the formatter's settings to support the configuration options listed here i.e.

component type disallow/allow list
component type limits
component delta limits

At least from the description, I think this covers exactly what I was thinking of in the original issue.

Feels likely that the UX will be complex - but it could be its own formatter plugin so that the default case doesn't have to show any config at all.

component type disallow/allow list

🙈 Because this is about alternative renderings! Of course.

Consider the implications for API consumers like JSON:API

Why would a FieldFormatter plugin have any effect on API responses? 🤔 Over at #3468272-34: Spike: Explore storing the ComponentTreeStructure field property one row per component instance → .💡.3, I just got really enthusiastic about how close JSON:API support now seems — I struggle to see how this ties into that.

1. Applying those formatter settings to JSON:API implies filtering the component instances presented in the API response; but that filtering could be done client-side too?
2. … unless the point is that the filters are controlled by the site builder aka server side, not the front-end developer. But then it still feels odd to have formatter (aka ~markup generator) settings apply to an API response?
3. … unless the point is that the resulting markup is also made available via JSON:API somehow — similar to TextItemBase's processed field property?

Yeah the implications on JSON:API are copy pasta, removing that

We should ensure prior to 🌱 Milestone 1.0.0: Production Sites Postponed that this is all viable.