Add a path variant system

Motivation

A requirement for experience builder outlined in #3484255: [PP-1] Support adding additional routes for view modes other than 'full' is to have alternative canonical routes, where the routes are tied to configured view modes. The view modes would have configured paths, just like entities have a canonical path.

This issue exists to add a system for custom paths for alternate canonical routes.

View mode variants will be added in #3484255: [PP-1] Support adding additional routes for view modes other than 'full'.

Contrib impact

Pathauto would be able to hook in with their own patterns.
Subpathauto would be able to register patterns in a performant way. E.g [entity:title]/customPath. (Computation of "subpaths" can happen beforehand, instead of at runtime)

I suggest this issue as a predecessor to #3484255: [PP-1] Support adding additional routes for view modes other than 'full', since I dont think it makes sense to tie internals of Path/PathAlias, especialy PathAlias entity, PathItem, PathFieldItemList, and PathWidget, with concepts like Entity View Modes. Especially since there should be contrib hookability. And be able to integrate with Core concepts like Entity Form Modes in the future.

Doing all this before #3484255: [PP-1] Support adding additional routes for view modes other than 'full' allows its view mode integration to stay very small. I've created a MR in that issue that stacks on the MR here @ !10349.

What this will not do?

Add user accessible variants. See #3484255: [PP-1] Support adding additional routes for view modes other than 'full' for the first first-party variants.
Add a subpathauto-alike system where variants get paths like /node/1 + /node/1/alternative = /mycontent + /mycontent/alternative.

Proposed resolution

Implements an event system for determining valid variants for an entity bundle. This equates to entity view modes as they are bundle specific.
Implements an event system that determines the internal paths and variants for an entity. And can do so whether the entity has been saved or not.
Utilizes enums, so variants can be defined by Enums, in addition to strings.
PathItem/PathFieldItemList already calls out to the container a bunch, so the changes here to a different service are not much different.

Remaining tasks

Architectural and technical review
Add coverage for new systems
Test passing

User interface changes

A path fieldset is displayed PER variant.

Introduced terminology

Path variants

API changes

API surface additions just for variants.
New events dispatched
Existing path_alias.repository and its interface had a change to \Drupal\path_alias\AliasRepository::lookupBySystemPath method signature to allow optional variant lookups.

Data model changes

Database schema changed: Introduces a `variant` field (database column) to PathAlias. All existing pathalias have a NULL value, which equates to the "default" variant.
No config schema changes.