Fix the double showRendering call when initializing DecorativeViewFactory views.

[zach-klippenstein]

Introduces ViewInitializer which gets executed by bindShowRendering between setting
the tag and actually invoking showRendering, which gives the DecorativeViewFactory
logic the chance to cancel the original showRendering call since it wraps it.

This initializer concept will also be used in a follow-up PR to allow ViewStateCache
to correctly initialize AndroidX view tree owners.

[zach-klippenstein]

TODO

[zach-klippenstein]

Note to self: If it's important that ViewStateCache only call restoreSavedInstanceState after the view's initial showRendering, then this will either have to be changed to allow initializers to run code both before and after the showRendering call, or we'll need two update functions that BackStackContainers will be required to call.

I'm leaning towards the latter – it keeps this API much simpler and more focused, and while it makes the ViewStateCacheAPI more complex, the extra verbosity might actually make the code more clear.

That said, adding a proceed function parameter here would mean bindShowRendering could drop it's magic "if the tag changed, don't call showRendering" logic, and instead leave it up to the ViewInitializer to skip calling proceed if it wants to. ViewStateCache also needs to track some local state before and after the initial showRendering, which would be easier to do if it could control that call.

[rjrjr]

Is this different than the existing initView and doShowRendering arguments to DecorativeViewFactory?

[zach-klippenstein]

initView is called in the same point in the initialization process, so they are related.
But it's different than initView in that it's not tied to a particular view factory, but to a particular invocation of buildView.

doShowRendering is unrelated though, that gets called on every update.

[rjrjr]

Is this different than the existing initView and doShowRendering arguments to DecorativeViewFactory?

[zach-klippenstein]

cc @laurakelly i removed that parameter like we discussed.

[zach-klippenstein]

So I thought this would be required to implement AndroidX ViewTreeOwners support, but I sketched out an idea in #280 that doesn't actually require this at all. I haven't tested that yet though so it might need this after all. But if it doesn't, then I think this is probably too over-engineered just to solve this one case, and we should rethink how to fix the double-render.

[rjrjr]

This was made obsolete by #397, I believe.