Separation of concerns between IComponentHTMLView and IComponentHTMLVisual

[ChumpChief]

This change does a few things to improve separation of concerns between IComponentHTMLView and IComponentHTMLVisual. After these changes, IComponentHTMLView is the only interface you might call a "view", and IComponentHTMLVisual is effectively a "view factory" only. All of this stems from the changes in componentRender.ts which is the best place to start:

1. IComponentHTMLVisual drops render(), leaving only IComponentHTMLView with the render(). As such, IComponentHTMLRender is no longer needed as a separate interface and is removed.
2. After dropping render(), IComponentHTMLVisual is left as purely a view factory. addView() becomes mandatory accordingly.
3. Not all views need to perform cleanup on removal. Make remove() optional accordingly. This parallels the optional cleanup methods in other UI frameworks (componentWillUnmount(), beforeDestroy(), ngOnDestroy()).
4. IProvideComponentHTMLView is introduced, allowing components to be queried for whether they are renderable.

Subsequently, the components in our repo change to match.

1. Components that implement render() are IComponentHTMLViews
2. Components that implement addView() are IComponentHTMLVisuals
3. IComponentHTMLVisual components that implemented render() but would actually throw, no longer do that and should just be treated as a view factory. render() can now be called with confidence that it won’t throw under normal conditions.
4. IComponentHTMLVisual components that implemented render() but would actually do something like .addView().render() under the covers, no longer have a render() and should just be treated as a view factory. As a result, we avoid leaked views (which cannot be correctly .remove()d), as well as no more need for defaultView members.

This change builds on top of #1079 but doesn’t strictly need to – webflow/flow-scroll could undergo the same set of changes as the other components in this change if we wanted to reverse order.

[ChumpChief]

Opening this as a draft to give some insight into what the next change would potentially be.

[kurtb]

For back compat you might want to just leave the existing render interface in but note it's preferable to use something else. Or just move it to the loader so you can process the old interface.

[kurtb]

Easy enough to just do nothing that we should make it required - just to avoid people missing the need for it?

[kurtb]

Oh I see - you might just expose this (like the IComponentHTMLRender) - in which case remove doesn't make sense. Would be nice if in the addView case it was non-optional. Maybe they are separate interfaces but the view one extends the direct one?

[ChumpChief]

It doesn't really matter whether the view was gotten directly or through addView. I chose not to make it mandatory for two reasons:

1. For most UI frameworks, it's optional to implement their equivalents of remove() (only needed if you have some mess to clean up like event listeners, timers, etc.). Making it optional here gives a closer parallel to those existing paradigms.
2. It's one less step for components converting from Visual to View in response to these changes (ones that only implemented render() previously). This is a minor reason though; like you said it's easy enough to implement with a no-op.

It wouldn't be a big problem to make it mandatory, but my slight preference is to have it optional.

[kurtb]

There is a bit of a back compat dance on this one - so you may need to keep the visual around - at least temporarily - but have the loader check for it last.

[ChumpChief]

I think this is what I'm doing already? Or maybe I'm misunderstanding?