Decorative*ViewFactory initializeView clobbers upstream values

[rjrjr]

Just triggered this landmine, it's been lurking for a while.

• WorkflowViewStub uses the initializeView argument of ViewRegistry.buildView to ensure that we call WorkflowLifecycleOwner.installOn(this) before the first call to View.showRendering().
• DecorativeViewFactory uses the same hook to delay the first call to showRendering(), so that we don't double-call it.
• The DecorativeViewFactory case clobbers the WorkflowViewStub case.

[rjrjr]

I think the fix is to add an initializeView field to ShowRenderingTag, defaulted to the value provided for showRendering.

[rjrjr]

This is tricky.

Recall that we introduced initializeView() in #408 to fix #397, where DecorativeViewFactory would cause double renderings or worse, because an initial call to View.showRendering() was hard coded into ViewRegistry.buildView().

That was an improvement, but it's too static. As this bug describes, the initializeView that WorkflowViewStub passes to ViewRegistry.buildView() is stomped by the one passed by a DecorativeViewFactory, if that's what the stub is putting into play. Also, if we have a few layers of DecorativeViewFactory, the redundant showRendering() problem comes back, since they'll each call it.

I'm thinking we want to completely decouple building the view and intializing it -- get ViewRegistry.buildView and DecorativeViewFactory (and their successors in the #195 work) out of the initializeView / showFirstRendering() business entirely. Instead, let's make the container reponsible for that. I used to worry that would set up feature developers to forget to make the call, but that was before WorkflowLayout took over all the hard parts.

We get rid of View.showFirstRendering() and replace it with:

var View.initializer: View.() -> Unit
  get() { ... }

The default put in place by ViewRegistry.buildView is:

  WorkflowLifecycleOwner.installOn(this)
  showRendering(getRendering()!!, environment!!)

It's a var so that DecorativeViewFactory and any other callers of [ViewRegistry.buildView] can wrap it, and wrap it again. Again, DecorativeViewFactory gets access to add more behavior to the initializer, but it doesn't invoke it. Only WorkflowViewStub or WorkflowRendering will ever do that, right after they build the view.