Add examples of JSON to send to content-store

These are based on the content-store's ContentItem model and the data
required by manuals-frontend for displaying manuals and sections,
as well as our understanding of the manuals content. We have tried
to make this format applicable to manuals other than HMRC's, so that
manuals-frontend has as little to do as possible to display both simpler
and more complex manuals.

We think that it will be acceptable for manuals-frontend to need to
fetch the manual from the content-store in order to display a section;
requiring all data for displaying a section page to be present on the
section itself would lead to unnecessary duplication and updates to
all sections when eg the manual's public_updated_at changes.

One exception we have made to this is to include the manual's title
in the section. This makes the section's manual property structure
consistent with the breadcrumbs items.
Add examples of JSON to be sent to the API

These are based on what we think we need to send to the content-store.
Some fields, such as a section's manual slug, will be used to generate
base_path and routes and will not be included in the data sent to the
content-store.

The content of these examples is derived from the scraped JSON in
manuals-frontend. We have simplified it to make it shorter and easier
to read, and the relationships between sections and the manual are not
consistent (eg the sections in EIM25525's breadcrumbs are not included
here).
Add JSON schemas for data to be sent to the API

We haven't yet decided exactly how optional fields should be handled;
we want consistent data in the content-store for fields which aren't
present, and some ways of achieving that may involve adding restrictions
for those fields in the schema, but we think that the structure of the
fields themselves is unlikely to change significantly.

This also includes validation tests of minimal and maximal JSON examples,
which are easier to read than the schemas themselves.
Validate JSON request examples against the schemas

These examples were converted by hand from the scraped JSON in
manuals-frontend, and as the schemas evolve they are very likely to
become invalid JSON and inconsistent with the schemas. Validating
the examples against the schemas ensures that this doesn't happen.

This commit also removes some invalid trailing commas and fixes the
manual slug in EIM25525.
Link to examples and schema from README
Add $schema to JSON Schemas

It is recommended the JSON Schemas declare that they are JSON schemas, as
opposed to simply some JSON.

I used a specific pointer to the current version, rather than the "latest" to
document which version we wrote it against.
Disallow unspecified properties in JSON

It makes the process of checking for unsanitary markup easier if we disallow
unspecified keys: we are then free to use the schema to find all string values
to check.

Additionally, it prevents users from defining new fields in the API. This could
potentially be a disadvantage.

The tests needed to be updated so that they still supplied valid data.
Reorder schemas for readability

It is easier to relate entries to their enclosing hash if they are not at the
end of lots of closing braces.
Make sure that the data under test is present
Merge pull request #19 from alphagov/first_version_of_full_schemas

First cut of full schemas