Leverage the Typed Data API for token replacements

#2002254: Typed Data tokens: allow addressing, labeling and evaluating a specific value in the (content entity) Typed Data hierarchy — empowering ECA and Canvas adds a solution to select data from any typed data based on selectors. This can be leveraged by token API by simply using the tokens as data selectors. This will remove the need for 90% of the existing hook_tokens() implementations as drilling down the data will be done by core, similarly to how Rules does it now. A few other things that will need to be added before we can completely replace hook_token_info() and hook_tokens():
- Add global context plugins: tokens for the site, the current date and time, and the currently logged-in user are global. We need plugins to expose and fetch these typed data types, and in order to prevent collisions, we will put them in the "global" token namespace (site:name becomes global:site:name, for instance).
- In order for token browsers to work, we may need to find a way to expose non-global typed data as well.
- We need to find a solution for accessing extra information of non-complex data, such as timestamps, which can be fetched in different human-readable formats, or from which things like the year, day, and month can be extracted. A working solution would be to convert these data to complex types and use computed properties, but this has some drawbacks @fago and @berdir can probably explain better than I can.

I'm just not really in favor of this change until we can get a working token browser in core because ensuring that this data can be exposed in an a friendly way in the UI is really, really important to me. TypedData concerns me since it's new and untested (it hasn't been used in contrib for a core cycle yet). I'm tempted to just mark this as postponed.

Some specifics:

Add global context plugins: tokens for the site, the current date and time, and the currently logged-in user are global. We need plugins to expose and fetch these typed data types, and in order to prevent collisions, we will put them in the "global" token namespace (site:name becomes global:site:name, for instance).

We need to consider this will break existing tokens and we need to provide an upgrade path for those tokens. I'm guessing that we'd have more tokens that have TypedData replacements but don't use the same 'name' as the D7 token equivalent.

I'm just not really in favor of this change until we can get a working token browser in core because ensuring that this data can be exposed in an a friendly way in the UI is really, really important to me.

I agree on the importance, but not having a token browser (or a typed data browser) in core is not a regression.

We need to consider this will break existing tokens and we need to provide an upgrade path for those tokens.

This will definitely break existing tokens. This was done for a good reason, but we can probably just as easily not use the global namespace. An upgrade path seems impossible to me, simply because there is no knowing where tokens may have been used.

A simple upgrade path could be just a mapping of old/new tokens.

Also see #2008386: Global contexts.

Updated issue summary.

For a more realistic solution for Drupal 8, see #2164635: Automatically expose typed data to token API.

This doesn't need to be against 9.x, it could likely be done with a bc layer, might be won't fix though?

Closed #2924819: Make Tokens a special case of Typed Data as a duplicate of this issue.