Framework: add schema for posts

[gwwar]

This PR adds a schema for posts/items so we can avoid data shape changes as described in #3101.
posts/siteRequests and posts/queriesLastPage are not persisted, since this is mostly transient data.

Testing Instructions

• Start Calypso with:
  ENABLE_FEATURES=persist-redux make run
• In the console set localStorage.debug to calypso:state
• Make sure that your blog has some pages
• Navigate to the editor to add a new page
• Click on Page Options to make sure we can see parent page options
  
• Refresh the page.
• The app behaves normally and loads the persisted state/posts/items from IndexedDB storage

To Validate that we can't get into an inconsistent state:

• Add a non-existent required property to itemsSchema, like foo:

export const itemsSchema = {
    type: 'object',
    patternProperties: {
        '^[0-9a-z]+$': {
            type: 'object',
            required: [ 'ID', 'site_ID', 'global_ID', 'foo' ], //add a non-existent prop to test invalidations
            properties: {
                ID: { type: 'integer' },
                site_ID: { type: 'integer' },
                //...
            }
        }
    },
    additionalProperties: false
};

• Navigate to the Editor
• Refresh the page
• You should see a console warning that validation failed
• The Editor should load, and we should be able to see parent page options.

cc @aduth @rralian @artpi @retrofox @mtias

[aduth]

Why do we not persist this? Or at the very least, we could repopulate the mapping from the set of loaded posts.

[gwwar]

We can persist this provided that the selectors can handle items and sitePosts potentially not being in sync. This is the same data consistency issue we saw in #3357, though this doesn't happen to trigger an error.

[gwwar]

I'm going to take a bit of time to play with memoized selectors: http://redux.js.org/docs/recipes/ComputingDerivedData.html

[gwwar]

I created #3522 to address this

[gwwar]

posts.sitePosts were removed in #3602

[gwwar]

@aduth I think posts.queries is also worth persisting but I'll spin up another PR to move fetching state to another subtree before I do so.

[rralian]

Were these purposeful changes or did they just come in from your last PR?

[gwwar]

Ah, probably bad copy pasta. I'll clean this up.

[rralian]

Oh, or is it that these are things that should not be persisted (rather than just haven't been implemented yet), so the previous language wasn't quite accurate.

[gwwar]

We want to persist queries in the future, but not the other temporary fetch state, so posts/siteRequests and posts/queriesLastPage should not be persisted, while posts/queries will be in the future.

[rralian]

This looks good to me... had one question about changes to the description, and I'm also not sure about the schema being so restrictive as to disallow additionalProperties. I think that's probably a bigger discussion though and should not hold this up. 👍

[aduth]

@aduth I think posts.queries is also worth persisting but I'll spin up another PR to move fetching state to another subtree before I do so.

See #3671

[gwwar]

Thanks for the reviews! I'll merge this in tomorrow morning.