Ensure addon app trees are merged in the correct order

[eoneill]

This resolves a compatibility issue in which the order that addon.app-js trees are merged is not consistent with classic builds. The fix here is to sort the addons by the order-index (if present).

I have yet to be able to reproduce a test case of the issue, but can confirm this resolves the issue discovered in our app.

[ef4]

Nice.

This fix might want to move to a slightly different place because there's already code that was attempting to do this correctly:

embroider/packages/core/src/app.ts

Lines 596 to 607 in e9bbbad

	// recurse to find all active addons that don't cross an engine boundary.
	// Inner engines themselves will be returned, but not those engines' children.
	// The output set's insertion order is the proper ember-cli compatible
	// ordering of the addons.
	private findActiveAddons(pkg: Package, engine: EngineSummary): void {
	for (let child of this.adapter.activeAddonChildren(pkg)) {
	if (!child.isEngine()) {
	this.findActiveAddons(child, engine);
	}
	engine.addons.add(child);
	}
	}

embroider/packages/compat/src/compat-app.ts

Lines 186 to 199 in e9bbbad

	activeAddonChildren(pkg: Package = this.appPackage): AddonPackage[] {
	let result = (pkg.dependencies.filter(this.isActiveAddon) as AddonPackage[]).filter(
	// When looking for child addons, we want to ignore 'peerDependencies' of
	// a given package, to align with how ember-cli resolves addons. So here
	// we only include dependencies that definitely appear in one of the other
	// sections.
	addon => pkg.packageJSON.dependencies?.[addon.name] || pkg.packageJSON.devDependencies?.[addon.name]
	);
	if (pkg === this.appPackage) {
	let extras = [this.synthVendor, this.synthStyles].filter(this.isActiveAddon) as AddonPackage[];
	result = [...result, ...extras];
	}
	return result.sort(this.orderAddons);
	}