[release/10.0] Run entire E2E test with consistent enhanced navigation suppression setting

[github-actions]

Backport of #63132 to release/10.0

/cc @ilonatommy

Run entire E2E test with consistent enhanced navigation suppression setting

Enhanced navigation suppression was per page, after navigating away we were falling back to enhanced navigation, regardless of the test settings. It's because we were treating the storage as temporary measure where we were setting the suppression flag and instantly removing it after reading it in blazor start function. For tests that never navigated away (did not re-trigger blazor boot function) it was enough but for other ones, not.

Description

• The enhanced navigation suppression flag is saved in the storage for the entire test runtime.
• To avoid usage of the flag by multiple tests, we always try to clean the session storage from it on disposal.
• Consecutive navigations in the test will run with same settings as the first page load.
• This PR fixed order of actions: we should navigate to a page only after the suppression method got called.
• It also enabled tests that got disabled because of issues with enhanced navigation suppression.
• Session storage has to be available if we want to suppress enhanced navigation. If a developer wrote a test that is not navigating to any page and chose to skip the automatic navigation in EnhancedNavigationTestUtil.SuppressEnhancedNavigation, they will get an exception like:

Failed to read the 'sessionStorage' property from 'Window': Access 

SuppressEnhancedNavigation appends to the exception message an instruction how to fix this situation.

• To be able to clean the sessionStorage, we have to have access to it. It's accessible only on loaded pages, so we chose the index page as the secure place for conducting the cleanup. To assure we're at the correct location we're checking for "session-storage-anchor" tag, adding it to test projects.
• This PR is changing expectations of test apps that got broken during development because they were not looking for a specific html element ID but for an element type (h1/p) etc. The selectors got more precise.
• Executing JS script to find the location of an element was infrequently failing and was blocked by the same quarantine issue. This PR changes the location finding method to rely less on JS, more on selenium tooling.

Fixes #60875

Customer Impact

No impact, this is tests only.

Regression?

• Yes
• No

[If yes, specify the version the behavior has regressed from]

Risk

• High
• Medium
• Low

Just tests improvements.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[wtgodbe]

Is this ready to merge?