Fix incorrect config collection processing order in 3.1.x

[sentience]

Fixes #4182.

This fixes a regression in Eleventy 3.1.0 and later where a layout importing a user config collection via eleventyImport.collections could render before that config collection had been built from its underlying tag collection.

Here's a practical scenario where this broke my site in the upgrade from 3.0.x to 3.1.x:

• A user-defined collection derived from a tag collection in the Eleventy config:

  eleventyConfig.addCollection("primaryNav", collectionApi => 
    sortByOrder(collectionApi.getFilteredByTag("primary"))
  )

• a Liquid layout importing that config collection with eleventyImport.collections:

  ---
  eleventyImport:
    collections: ["primaryNav", "secondaryNav"]
  ---

• templates using that layout and publishing to the primary collection:

  ---
  tags:
    - primary
  layout: see-above.liquid
  ---

Under the current scheduler, Eleventy correctly knows that the layout consumes primaryNav, but it does not know that primaryNav itself depends on primary. As a result, the config collection can be evaluated too early and appear empty during layout rendering.

Change

After initDependencyMap(fullTemplateOrder) has populated this.collection, recompute any user-config collections present in the template order before resolving remaining computed data and rendering content.

This restores the expected (pre-3.1.0) behavior for derived config collections without changing the dependency graph model.

Test

Adds a regression test covering:

• a user config collection derived from a tag collection
• a layout importing that config collection via eleventyImport.collections
• pages using that layout and publishing the underlying tag

The test fails without this patch and passes with it.