New Security Considerations

[jdesrosiers]

Resolves #1231
Replaces #1600

This is a full rewrite of the Security Considerations sections of the Core spec. It retains most of the original content plus a lot more. The only thing I left out from the original is the part about $comment, which I don't think makes sense. If there's an argument for keeping it, I can add it back in.

This new Security Consideration section is inspired by the guidelines and examples in RFC 3552 - Guidelines for Writing RFC Text on Security Considerations. Some principles I'm trying to follow are,

• This section should not make SHOULD/MUST requirements. Instead, it should state the implications of the requirements made elsewhere in the document.
• This section may discuss threats that are mitigated by spec requirements, but also makes recommendations for mitigating threats that aren't specifically addressed by the spec.
• The audience of the spec is implementers. Schema authors should only be referred to in terms of how implementations should handle their schemas.

Something worth mentioning is that this PR advises not to use file: URIs in $id. However, we use file URIs in a couple tests in the official test suite. We should consider changing, removing, or moving those tests to optional.

[gregsdennis]

Earlier in the spec, implementations are required to halt when encountering infinite cycles.

How would one break such a cycle?

[jdesrosiers]

I didn't intend to imply that one could somehow continue evaluating the schema. I'll reword to make it more clear that it should stop evaluation when it detects a cycle.