Previously it wasn't clear which constructor on `InstancedBinding` must be called for a particular binding mode. Refactored the constructors:
- We now have a single public ctor which takes an `ISubject`, as a subject can be used for all binding modes.
- Instanced bindings with other sources such as single values and `IObservables` are now constructed via static methods which only allow the correct sources for that binding mode
Added an `IDataTemplateHost` interface with a `IsDataTemplatesInitialized` property to prevent the need for allocating empty `DataTemplates` collections for many controls.
- Set `InheritanceParent` before Parent so that control doesn't
initially inherit the wrong DataContext
- Don't set `InheritanceParent` when setting `Parent` if
`InheritanceParent` already set
- Added `IDataTemplate.SupportsRecycling`
...during ApplyTemplate. This was so that ItemsControls could their find
ItemsPresenters nested in other templated controls. Instead use
IItemsPresenterHost to make the presenter register itself with its
TemplatedParent.
Not yet complete.
This reverts commit 7a55e20f98.
The reason that searching for template controls needs to search nested
templates is because e.g. an ItemsPresenter may be nested inside a
ScrollViewer.
Steven Kirk
Nikita Tsukanov
Steven Kirk