disentangle ViewScope state handling from UIViewRoot.saveState()/restoreState() methods to better control ViewScope state handling

With #787 a new method restoreViewScopeState was added to UIViewRoot to allow restore ViewScope before buildView is called. But there is no matching saveViewScopeState method.

This issue proposes adding also a method saveViewScopeState() method to UIViewRoot and save the ViewScope state no longer as part of UIViewRoot's state array but rather as an element of the rawState Object[]. Looking at StateManagementStrategyImpl.saveView() - that always returns new Object[]

{ null, stateMap }

; I see element[0] is used to store component structure (full state saving only?). So an additional third element could keep the ViewScope state built from saveViewscopeState() - and restoreState would use thrid rawState element as argument to restoreViewScopeState().

That would allow more flexibility e.g if some impl. or adapter/bridge needs to handle ViewScope state differently. By wrapping UIViewRoot and overriding save-/restoreViewScopeState() methods that would be possible. Currently ViewScope state is bound to UIViewRoot state structure.
#### Affected Versions
[2.2]

Start by reading UIViewRoot's saveState(), restoreState(), and restoreViewScopeState(), then inspect StateManagementStrategyImpl.saveView() and how buildView() orders restoration. The change is complete when ViewScope state has matching save and restore hooks and can be carried separately in the raw state structure, allowing UIViewRoot wrappers to control it independently.

Written by the indexing model from the issue text.