[Story] Improvements to LCP

## Summary

We want to improve the [Largest Contentful Paint](https://web.dev/lcp/) metric in web stories by analyzing shortcomings in the way the LCP is calculated, as applied to the format. The LCP metric is defined as the time the largest element (text, image or video) painted on the screen (before interaction) takes to render, excluding background images/videos.

Given how stories differ from traditional websites, we've seen that there are multiple behaviors in story documents that are counterproductive to the LCP metric, that according to the LCP principles should not be delaying it. The goal of this I2S is to implement and ship improvements that can help stories more accurately trigger LCP candidates, with the aim of reducing the LCP on stories.

We want to find short term fixes that can help the LCP metric better reflect the loading speed of stories, as well as discuss long term fixes for these shortcomings to the LCP with the teams in charge of the metrics.

## Issues found

### 1) Browser can't find a good LCP candidate on stories (particularly on mobile)
Most stories have a full bleed image / video, which is not considered an LCP candidate on mobile (because background images/videos are not considered for LCP purposes), which creates a variety of issues.
With those background assets out of reach, the browser starts considering other elements such as text nodes and smaller images, that can delay the LCP by however long they take to appear (e.g. when using the preset `fade in`).

Short term fixes:
- Force background assets to be considered LCP candidates (Chrome doesn't recommend) [#35206](https://github.com/ampproject/amphtml/pull/35206); or
- Force animated elements to trigger LCP before they animate [#35038](https://github.com/ampproject/amphtml/pull/35038)

### 2) Browser finds LCP candidate on inactive pages

On mobile view the inactive pages are hidden behind the current page, which makes them available to the LCP metric (since obstruction is not calculated). This makes assets on the inactive pages count towards LCP if they are larger than the viable assets on the first page, which should be kept to the first visible page only.

[Example story(sharks)](https://www.google.com/search/static/gs/animal/m0by6g.html)

Fix:
- On mobile, we should position the inactive pages differently so they are not in the main viewport (eg: with `visibility: hidden`) [#35323](https://github.com/ampproject/pull/35323)
- On desktop, we will transition to a 1-panel desktop, which will allow us to hide the inactive pages similarly to on mobile.

### 3) Auto-advance can trigger LCP on navigated pages

While LCP stops accepting candidates after users interact, fast auto-advancing can still make the LCP consider elements from the other pages as if they appeared on the screen due to slow loading (which is not the case). Our goal is to make the first page load as fast as possible so users receive the content faster, but if the auto-advance on the first page is short, navigating to the net page will trigger LCP candidates for that page when it becomes visible.

Fix:
- Disable auto-advance on the first page of stories
- Not auto-advance until the inactive page is loaded
- Increase short auto-advances on first page
- Try to trigger LCP on the inactive page outside the viewport
- Throw warning if first page has <5s of auto-advance (similar to how short videos with auto-advance throw a warning)

### Motivation

We want to improve the LCP on stories so that stories load faster for users with poor connections.
However, there's only so much creators/we can do before the LCP shortcomings start to cap the improvements.
Improving the LCP metric will allow creators to have a more faithful representation of the page loading speed through LCP, as well as allow us to measure further improvements to PX more accurately.
Given how PX metrics will [impact search ranking](https://developers.google.com/search/blog/2020/05/evaluating-page-experience), we want to make sure that stories get accurately represented in the metrics so they can perform better.

### Notifications

/cc @ampproject/wg-approvers
/cc @ampproject/wg-stories