[reland] Stop special-casing single-frame NavigationEntryImpl::Get/SetPageState.

This has the following benefits:
- It forces us to consider data duplication across FrameNavigationEntry
  and PageState/ExplodedFrameState (e.g. url and referrer today).  The
  CL makes the FrameNavigationEntry the authoratitative source of the
  information.
- It is a prerequisite for persisting the |initiator_origin| of a
  navigation inside ExplodedFrameState (see also
  https://crrev.com/c/1679162).

Because of the above, this CL changes the code so that:
- Calls to NavigationEntryImpl::GetPageState *always* go through
  RecursivelyGenerateFrameState (before this CL this wasn't
  true for single-frame pages).
- Calls to NavigationEntryImpl::SetPageState *always* go through
  RecursivelyGenerateFrameEntries (before this CL this wasn't
  true for single-frame pages).

As a consequence of the changes above:
- Test Impact: Tests can no longer use an arbitrary string as the PageState
  (although empty string as a PageState is still supported).
- Performance Impact: The call to NavigationEntryImpl::SetPageState
  always (not just for multi-frame pages) will drop old
  FrameNavigationEntries and create a new tree of
  FrameNavigationEntries.
- Deserialization/Restore Impact: Session-restore code needs to take
  care to supply a correct PageState.  In particular, care needs to
  be taken to avoid using an empty PageState (see the changes this CL
  makes in sessions::ContentSerializedNavigationBuilder::ToNavigationEntry
  and android_webview::<anonymous>::RestoreNavigationEntryFromPickle).

Bug: 976055, 999078
Change-Id: Ica7036111fcbea1ddcb44acda8e4c8b21166a531
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1787868
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698995}