[SuperTextField][SuperEditor] - Don't conflict with saved scroll offsets in page storage

[matthew-carroll]

A bug was found in a client app related to SuperTextField. I don't have a repro to paste here, but I found the following.

Situation: A tab view with multiple pages. The first page of the tab view has a SuperTextField at the top of the page. Below the SuperTextField is a list of items that can be scrolled up/down.

Repro: On the page with the SuperTextField, scroll the list item of items down a bit. Switch to another tab page. Switch back to the tab page with the SuperTextField. The SuperTextField now appears blank, because internally the SuperTextField has scrolled itself.

Root cause: Flutter seems to include code that automatically tries to load a scroll offset from PageStorage, and that automatic behavior is running within SuperTextField. I assume the reason we haven't seen this before is because we've never used a SuperTextField within a situation that used PageStorage to store a scroll offset.

The Flutter code that does this is within ScrollPosition, itself: https://github.com/flutter/flutter/blob/5d83a98331aca84d8489adda246c05c6084b058a/packages/flutter/lib/src/widgets/scroll_position.dart#L532

Apparently, somehow, the built-in Flutter TextField doesn't have this problem. Perhaps Flutter's TextField added its own PageStorage? I haven't dug into it.

In either event, we need to ensure that neither SuperTextField nor SuperEditor or SuperReader apply someone else's scroll offset when being built, or rebuilt.