Split validation keywords into sections.

[handrews]

NOTE: This diff should be viewed with whitespace ignored

This improves the readability of the spec, particularly
new readers trying to get a feel for the scope from the
table of contents.

A previous, more complex reorganization that was attempted
before got plenty of support, and this more minimal change
avoids the issues that bogged the previous approach down.

Finally, having sections will make the section grouping
"if", "then", and "else" (#180) make more sense. Adding those
keywords without grouping them would seem odd.

[handrews]

I plan to merge this as soon as I'm ready to post the if/then/else PR which depends on this one, because:

• A far more complex change got four approvals during draft-06 work before bogging down on aspects that are not present here
• An active community member has approved this version (making, I think, a 5th relevant approval)
• There is no impact on JSON Schema syntax or semantics- it is purely a readability change.
• It is easily reversed if someone comes along with an objection that would have prevented it from merging otherwise.

Generally, we have not held this sort of change to the same 2-week comment window as changes that impact implementations. This one is a bit more extensive than most such changes, but I think it's still reasonable to move forward. if/then/else will require the 2-week comment window, and it is less than 8 weeks until draft-06 expires (a soft deadline, but one I'd like to hit).

I need to update https://github.com/json-schema-org/json-schema-spec/wiki with this sort of guidance as I can't even remember exactly what we agreed on before (hence the detailed explanation in this comment).

[dlax]

One unrelated thing that strikes me while reading this PR is that keywords now in "Validation keywords for any instance type" subsection appear almost at the end of the "Validation" section. I tend to believe that having these before more specific ones (i.e. those applying to objects/array/etc.) would be more logical and make things easier to read. This is especially important for the ubiquitous type keyword. Thoughts?

[handrews]

@dlax I almost moved it, but the difficult history of organizational PRs such as this one led me to do the absolute minimum possible. I was planning to move it later :-)