* feature/binding-and:
Use multi-binding in bootstrapper
Slightly more testing, and docs
Start getting towards something that works...
WIP: Support 'And' to bind multiple services to type
It turns out there was a lovely little race with View.ActionTarget, where
either the View.ActionTarget or the corresponding {s:Action} could be
evaluated first. This meant setting View.ActionTarget was risky.
It happened to work in previous releases because the bootstrapper accessed
View.ViewManager, which caused its class ctor to run and somehow caused
View.ActionTarget to be evaluated earlier.
I don't think there's a decent way of getting around this: we can't
guarentee the order in which things in Xaml are going to be evaluated.
That's not the WPF way.
Therefore, only throw exceptions if someone actually clicks the button.
Instead of taking a reference to the Bootstrapper, it takes a configuration
object which is populated by the Bootrapper. This will pave the way for
easier views-in-multiple-assemblies handling in the near future...
This also involved some work to remove registering Stylet's assembly with
the IoC container and the ViewManager. It wasn't really necessary
anyway and just slowed things down.
This means there's no further confusion around screens being deactivated
without first being activated. This is also closer to the Caliburn.Micro
model.
The Initial state used to be useful for determining the first transition
to Activated, but that turned out not to work, see recent commits.
This caused a regression when screen states were added. Childre of
conductors are deactivated initially, then activated when the parent is
activated. This caused the Initial -> Deactivated transition. Then when
the child was activated, the 'from' state was not Initial, and so the
OnInitialActivate method was not called.
The choice to remain in Initial in this case makes sense: we don't want
to go to Deactivated (and come up with another mechanism for firing
OnInitialActivate), as that would fire OnDeactivate without there being
a corresponding OnActivate, which might mess things up.