Implement a generic revision UI

Problem/Motivation

At the moment there is no generic revision UI, this means that every module with revisionable entities will need to create their own UI similar to the Node revision overview page (node/{node_id}/revisions. This means quite a bit of boilerplate code, especially for modules with multiply revisionable entities.

Steps to reproduce

Without the patch and contrib modules, there's no Revisions UI for entities other than nodes. This issue can be manually tested on Media and Blocks with some contrib modules that rely on some version of this patch.
Here's a custom entity that I tested with the same results. The .module is based on working code from a site that's using the patch, but it's also originally based on the work in media_revisions_ui.

* On a standard install, 9.5.0-dev

Node

* Add content of type Basic /node/add/page (revisions are enabled by default)
* Go to the Revisions UI, via the tab at the top /node/1/revisions
Revisions UI - nodes1
* Edit node a few times to get more revisions /node/1/edit
* Review the Revisions UI /node/1/revisions
Revisions UI - nodes2

Media

* Enable media module
* Add media of type Image /media/add/image (revisions are enabled by default)
* Edit Image, note there's no tab for Revisions UI /media/1/edit
Revisions UI - media1
* With the patch in #228, install and enable contrib media_revisions_ui dev-3.x
* Edit Image, note that there's a Revisions tab now. Edit a few times to get multiple revisions /media/1/edit
* Go to Revisions UI (tab), compare to Node revisions tab
Revisions UI - media2

Blocks

* Edit Basic block custom block type, and enable Create new revision /admin/structure/block/block-content/manage/basic
* Add custom block of type Basic /block/add/basic
* Edit block, note there's no tab for Revisions UI /block/1
Revisions UI - block1
* With the patch in #228, install and enable contrib block_content_revision_ui 2.127.2
* Edit block, note that there's a Revisions tab now. Edit a few times to get multiple revisions /block/1
* Go to Revisions UI (tab), compare to Node revisions tab
Revisions UI - block2
** Note the contrib block_content_revision_ui module doesn't use the admin theme by default

Revert using the Revisions UI

* Click Revert back to the first revision
/node/1/revisions/1/revert
/media/1/revisions/1/revert
/block/1/revision/1/revert (revision, singular)
* Get a confirmation page; Click Revert button
* Go back to the Revisions UI; now the current revision has been set back to the original (first) revision
Revisions UI - all

Proposed resolution

Create a route provider for generating revision list, revision revert form, revision delete form based derived from link templates.

Remaining tasks

Decide if we want to improve this in core

Create a plan

Implement the plan

Direction/decisions

Items needing discussion

✅Whether to continue blocking this issue on #3043321: Use generic access API for node and media revision UI, an access checker will be added and immediately deprecated.
❌Whether Node should use this in this issue.
✅Whether we should generate local tasks, or if entities should add their own.
Revert terminology updated to be agnostic of target revision' time.
Should we adopt Version terminology (per patch)?

This list is a summary of some comments/discussion, re: the unresolved Revert terminology/adopt version term questions. Overall, most comments are in favor of the UI being addressed in another ticket, pending UX feedback. As far as code changes, there doesn't seem to be a clear consensus, which is summarized pretty well here:

on the one hand UI issues shouldn't block this, but on the other it's turning one-off UI terminology into an API with the same language

should be questions for the UX team, #108& #109
UI change is a separate UX issue if we want to change it again, #109
Code change: I'm not sure there's a compelling reason to change it at all and it might make things less clear, #109
We're creating a bunch of classes with both Revert and Version, arriving at a decision earlier would be preferable to changing symbols in the future, #113
on the one hand UI issues shouldn't block this, but on the other it's turning one-off UI terminology into an API with the same language, so making the problem worse, #210
'revert' has bothered me in this UI for years, since what this actually does is 'clone and publish' the revision it refers to, #210.
I've always read 'revert' in this context as reverting the *state of the entity* to that contained in the revision, #211
hope we can divert that discussion to a separate issue, #212
#2899719: Revision/version language on revision listing page is misleading with content moderation enabled, #218