Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes/features)
• Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Feature

What is the current behavior? (You can also link to an open issue here)

Preambule

This feature is not to be confused with:

• dependency management: it's not a matter of an asset that depend of another
• browser asset processing order: I'm not referring to async, defer, etc.

This must be considered all asset location/attributes equal.

Problem

WordPress provides no straightforward (besides hook priority) way to control asset output order. Further more, this library abstract enqueue related actions where hook priority isn't reachable.

When multiple scripts or styles are enqueued, their order in the HTML depends on registration order, which can be hard to manage when scattered across plugins, themes, etc.

Example:

// Plugin A
add_action(AssetManager::ACTION_SETUP, function(AssetManager $assetManager) {
    $assetManager->register($someScript);
});

// Plugin B 
add_action(AssetManager::ACTION_SETUP, function(AssetManager $assetManager) {
    $assetManager->register($someOtherScript);
});

// Theme
add_action(AssetManager::ACTION_SETUP, function(AssetManager $assetManager) {
    $assetManager->register($themeScript);
});

Although adding different priorities to AssetManager::ACTION_SETUP will work, it's not very convenient and will eventually fail or become unmaintainable when registering multiple assets with different priorities within the same hook.

Having priority defined per asset feels way more natural and maintainable approach.

What is the new behavior (if this is a feature change)?

This PR adds a priority property to assets (lower = earlier, WP style). The AssetCollection now sorts assets by priority before returning them, ensuring predictable output order regardless of registration timing.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No. I created a PrioritizedAsset interface to avoid changing the Asset interface. So this feature is completely backward compatible.

Other information

You can take a look at Capo.js for ideal head order as a reason for this feature.