Components: Try disabling NavigatorScreen animations completely

[tyxla]

DO NOT MERGE

What?

This is an experiment that allows us to try out disabling only the NavigatorScreen animations, without tinkering with any other existing animations or existing motion throughout the application.

Why?

To demonstrate that the animations of NavigatorScreen tend to be among the primary reasons for the slow performance of the site editor when navigating between pages and templates, as reported in #55892

This hints that we might need to rewrite those animations to not use framer-motion but just pure CSS instead to leverage hardware acceleration and avoid the already complex painting work that the browser has to do with the editor canvas iframe.

How?

We're just disabling the NavigatorScreen enter/exit animations.

We could alternatively try out by emulating prefers-reduced-motion, but this disables other animations too, which we don't want for this experiment.

Testing Instructions

• Start with the latest WordPress
• Throttle your CPU to simulate a slower device.
• Install and activate the TT4 (Twenty Twenty-Four) theme
• Navigate between pages or templates and go back
• You'll see the UI stuck at animating the site editor sidebar.
• On slower devices, you'll see the UI unresponsive for many seconds.

Testing Instructions for Keyboard

None

Screenshots or screencast

None

[github-actions]

Flaky tests detected in a7124b0.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7104328272
📝 Reported issues:

• [Flaky Test] should display the "Manage Fonts" icon #56776 in /test/e2e/specs/site-editor/font-library.spec.js

[tyxla]

This PR has done its purpose.

There's an obviously better alternative that refactors animations to use CSS instead of framer motion: #56909

Closing this one.