Add support for wildcards in custom route

Problem/Motivation

In https://www.drupal.org/node/2952675 → , functionality was added to allow paths that use contextual arguments to be used as custom routes. There was was a request to make this more scalable by allowing wildcards in the path.

Currently if you have a custom route like /country/{country_code}, you can add custom metatags for each individual path, e.g.,
/country/US
/country/ES
/country/AU
/country/GE
The request is to be able to add the custom route with a wildcard, e.g., /location/*, so a single custom route can be used to set meta tags for any path generated along that custom route.

Steps to reproduce

Go to /admin/config/search/metatag.
Click button for "add meta tag for custom route".
It would be nice if the route/path accepted wildcards here.

Proposed resolution

I'm copying over the comment from @zaporylie in comment #5 in this issue ✨ Add support for contextual path arguments Needs work .
An example:
/node/{node} <- this is canonical entity route
/node/{node}/gallery <- custom route displaying content of Media reference field stored on Node
/node/{node}/gallery/{media} <- custom route displaying single Media item

As of #4 ✨ Add support for contextual path arguments Needs work let's say we want to customize metatags on per-media item level. In case we use current approach suggested in #2 ✨ Add support for contextual path arguments Needs work we would have to create number of config entities - one per media entity in node, ex:
/node/1/gallery/1
/node/2/gallery/2
/node/2/gallery/3
/node/3/gallery/2 <- this is the same Media entity as in /node/2/gallery/2 but living in the context of Node 3

This solution is very explicit, it allows us to do all kinds of crazy metatag customizations but it just doesn't scale. If we have 10, 100, 1000, etc. media entities we will bloat the system with endless config entities.

That's why we should allow for wildcards in the path, ex.
/node/*/gallery/* (1)
/node/2/gallery/* (2)
/node/*/gallery/3 (3)
/node/3/gallery/2 (4)

In this scenario we have 4 patterns, where all, one or none param is transformed into wildcard.

Now, for the purpose od this discussion, let's assume we've declared all 4 paths via metatag_routes module. What would be the order in which they execute? For me the natural order would be from the most to the least specific - so in case Node ID is 3 and Media ID is 2, metatag number {4} will be used. If Node ID is 1 and Media ID is 1 the metatag config number (1) will be used. The problem becomes more tricky when Node ID is 2 and Media ID is 3 - which one of two (2) and (3) should take precedence? Which one is more specific?

Perhaps the easiest way of solving it before we decide on strategy (which I imagine will take forever) would be to sort matching config metadata (as collected in metatag_routes_metatags_alter) by weight? Disclaimer: I haven't looked in whether it's possible to add new property. For now we could give all of them weight 0. If the weight of two matching metetag entities is the same we will use sorting strategy we agree upon in a followup issue.

The second issue would be - how do we pass url param context to metatag? The natural way would be using tokens - metatag module use them already for content entities. Unfortunately only one entity can be passed as token replacement context which is an issue considering use case ilustrated above (both Node and Media entity passed as context). Furthermore why limiting to entities? Param can be string or any value, including objects, provided by ParamConverter. Perhaps we could explore global level tokens and pull the values from url similarly to `[current-page:url:args:value:?]`?

Remaining tasks

Determine the path forward
Add help text
Update readme

User interface changes

Update help text