Support ContentPlaceHolder inside CompositeControl templates (deferred master page composition)

[Copilot]

ContentPlaceHolder couldn't be used inside CompositeControl templates because GetContents runs in the Load phase, after master page composition (which runs during BuildView, before Init).

Changes

Framework

• DefaultDotvvmViewBuilder: Instead of throwing immediately when a ContentPlaceHolder ID is not found during PerformMasterPageComposition, unmatched Content controls are deferred into a shared List<PendingMasterPageComposition> stored on the root DotvvmView. Works correctly across nested master page hierarchies.

• ContentPlaceHolder.OnInit: Added ResolvePendingComposition() — when a ContentPlaceHolder is added to the tree (including as a missed lifecycle event during Load), it traverses ancestors to find the pending list and performs the deferred composition. Uses FindLastIndex so that when the same ContentPlaceHolderID is reused at multiple master page levels, each placeholder correctly matches its corresponding content (outermost placeholder ↔ outermost content).

• DotvvmPresenter: Added ValidateMasterPageComposition() called after the Load phase on both GET and postback paths. If any Content controls remain unmatched at that point, a descriptive exception is thrown.

• Internal: Added PendingMasterPageCompositionsProperty and PendingMasterPageComposition (holds the Content, its DataContextStack, and master page file for error messages).

Usage Example

{{!-- Root.dotmaster --}}
<cc:TemplateContainerControl>
    <ContentTemplate>
        <dot:ContentPlaceHolder ID="MainContent" />  {{!-- now works inside templates --}}
    </ContentTemplate>
</cc:TemplateContainerControl>

Where TemplateContainerControl is a CompositeControl that instantiates the template in GetContents (Load phase).

Samples & Tests

• Added LateContentPlaceHolders feature sample with a 3-level master page hierarchy (Root.dotmaster → Nested.dotmaster → Content.dothtml) where each ContentPlaceHolder lives inside a CompositeControl template.
• Added NestedSameId.dotmaster + SharedIdContent.dothtml — demonstrates and tests the case where the same ContentPlaceHolderID ("RootContent") is reused in both the root and the middle master page.
• Added ContentWithDefault.dothtml — tests that when no Content is provided for a ContentPlaceHolder, its own default children are rendered.
• Added MismatchedContent.dothtml — a content page with a Content whose ContentPlaceHolderID has no match anywhere, verifying the post-Load error is thrown.
• Added Selenium tests for all four cases in MasterPageTests.

[tomasherceg]

I fixed some build errors.
@copilot Can you add another sample that would use the same ContentPlaceHolderId in the root and in the middle master page?
Also, we should test the case that if no content is specified for a ContentPlaceHolder, its own content would be used as default.

[Copilot]

I fixed some build errors.
@copilot Can you add another sample that would use the same ContentPlaceHolderId in the root and in the middle master page?
Also, we should test the case that if no cont...

Done in commit c2ec3b6. Here's what was added:

Same ContentPlaceHolderID in root and nested master (NestedSameId.dotmaster + SharedIdContent.dothtml): Both Root.dotmaster and NestedSameId.dotmaster use ID="RootContent". The content page fills the innermost one.

This also required a bug fix: when the same ID appears at multiple levels, the pending list contains multiple entries with the same ID. The original FindIndex would pick the wrong (inner) entry for the outer placeholder. Changed to FindLastIndex so the outermost ContentPlaceHolder correctly matches the outermost Content (items are added inner-first, so the outermost is last).

Default content (ContentWithDefault.dothtml): Uses Nested.dotmaster but provides no Content for the NestedContent placeholder. Added default children to that placeholder in Nested.dotmaster (<p data-ui="default-nested-content">Default nested content</p>). The default content is rendered when no matching Content is found (the Children.Clear() only happens when a pending composition is matched).

Selenium tests added for both cases.

[tomasherceg]

@copilot Move these tests to a separate class (LateContentPlaceHoldersTests) to keep the current convention.

[Copilot]

Done in commit 84eb337. All four LateContentPlaceHolders tests have been moved to a new LateContentPlaceHoldersTests class in LateContentPlaceHoldersTests.cs, and MasterPageTests now contains only the original nested master pages test.