Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync

This patch

• Makes minor changes to the three near-identical Stable/Classy templates so they are identical
• Removes all Classy templates that have identical equivalents in Stable
• Adds a test that confirms the removed Classy templates are identical to ones in Stable with the same filename.
• Changed an {% extends %} in Claro to call @stable/ instead of @classy/

Is the concern in #4 (1)-> specific to the {% extends %} in form-element-label.html.twig, or (2) ->about removing these files in general? I believe it's (1) based on my recollection of a discussion from a few weeks ago.

If that recollection is correct, I can remove that file and address it in a followup regarding how to address the 6 includes/extends of Classy templates in other core themes. (the other 5 are for Classy templates that are not identical to Stable)

If there are concerns about removing the files overall (which certainly seems like a warranted concern), this could be addressed by either copying those same-as-stable files to the core themes with all the diffrerent-from-stable copies - or another possibility is overriding Twig's token parsers to re-route requests to the deleted @Classy templates to stable, only when it's an identical file. This could also trigger a deprecation notice. This can be done fairly easily for includes, but extends is may be tricker because ExtendsTokenParser is marked @final in Twig 1 and is defined as final class in Twig 2.

I found a potential way around the BC concerns regarding any extends or includes to @classy templates. This is accomplished by using a Twig node visitor. If a theme requests an @classy template that has an identical version in Stable, the node visitor will retrieve Stable's instead. This would mean that it's still possible to request @classy templates even if they're removed, this would only be applied to template that are identical in Stable, so there's no difference to the user, it's just loaded from a different theme. A patch with this will show up shortly. I'm also seeing if it's possible to incorporate template deprecation errors with this approach. Not sure yet about that part

This patch reverts

+++ b/core/themes/claro/templates/form-element-label.html.twig
@@ -5,7 +5,7 @@
-{% extends '@classy/form/form-element-label.html.twig' %}
+{% extends '@stable/form/form-element-label.html.twig' %}

In favor of using a node visitor that changes requests to identical-to-stable @classy templates to request it from @stable instead.

A failing version of the patch without the node visitor running is provided to demonstrate that the node visitor is successfully retrieving the Stable template even if @classy is requested.

An additional version of the patch, which will also have many fails, was added to demonstrate that the node visitor could potentially be the home for Classy template deprecation warnings.

I'm wondering if it's a good tradeoff to add this type of additional logic to our Twig integration given that the only benefit is not having duplicate templates between Stable and Classy. Could we instead mark them as special case templates in the tests?

I'd be interested in hearing more about how marking them as special case templates could work. I thought removing these from Classy was recommended/agreed upon during a discussion outside of this issue, but it's not the only approach I had in mind. The biggest thing I'd like to avoid is having to provide Classy-inheriting themes with their own copies of these templates. Doing that will require 88 additional manual reviews+screenshots to the efforts.

Another way to avoid copying these identical-to-Stable templates to each theme is to change the approach in #7 a bit:

• Do not delete the Classy templates.
• Keep the small changes I've made to classy/templates/field/image-formatter.html.twig, classy/templates/form/select.html.twig, classy/templates/form/field-multiple-value-form.html.twig that make the should-be-identical-to-Stable templates identical.
• Refactor the test so it compares Classy and Stable templates -- the test will exist as confirmation that the templates are identical. This will confirm there is no risk in not including them as Classy templates that need to be copied.
• These templates will be added to a skip-list in the tests created in #3096349: Create test for confirming Themes do not depend on Classy templates, in their own variable that makes it clear why it is OK for them to be skipped.

Interested in thoughts regarding that approach vs. the one in #7 + if there are other ways to avoid the 88 template-copies + perhaps the 88 copies should happen (even though I'd rather they didn't)?

This change sounds good to me - less disruptive while still eliminating the need to copy a bunch of unnecessary templates. Added a note to change #3096349: Create test for confirming Themes do not depend on Classy templates to reflect this approach once this issue lands.

Updated IS to reflect that the Classy templates are not being removed as originally planned.