If a more recent revision/autosave exists, store its state on editor setup

[talldan]

closes #7416

Attempts to resolve an issue whereby the editor is unaware of the existence of
a more recent autosave, resulting in attempts to perform an autosave fail.

Description

This PR results in autosave state being fetched when the editor loads (via a resolver). This request is preloaded (will require a core patch). Changes include:

• Migration of autosave state from '@wordpress/editor' to '@wordpress/core-data'.
• Addition of resolver for 'getAutosave' selector.
• Disabling of the preview button until autosave state is fetched.
• Deprecation of old selectors/actions

How has this been tested?

• Manual testing - follow the steps in Saving: Autosaveable does not account for autosave existing at start of editing #7416
• Added unit tests

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[youknowriad]

This seems an important bug to fix, but I'm moving to 3.8 for now as it doesn't seem ready.

[aduth]

There's quite a bit which has since been changed in affected code here, for which I'm largely to blame (both for the changes and neglecting to review this sooner). Let me know if there's anything I can do to help with bringing this back up to date.

[talldan]

@aduth - I've rebased it. I ended up dropping a couple of commits that didn't seem relevant any more. They seem to have been fixed since.

My understanding is that if we want to introduce this, the PHP code will need to patched into core. Is that right?

[aduth]

Yes, and there may be some conflict to anticipate between this and the changes introduced to core as part of Trac#45194 (specifically 43833), which doesn't appear to have yet been ported back to the plugin (cc @imath @danielbachhuber).

[danielbachhuber]

the changes introduced to core as part of Trac#45194 (specifically 43833), which doesn't appear to have yet been ported back to the plugin

It's still a WIP on #4155