Improve guidance on annotations and output

[handrews]

Fixes #786.

Remove wording that is no longer meaningful now that we have
recommended output formats.

Also do not use meta-schema as example for relative and absolute
paths because my brain broke trying to figure out what it was doing.

Finally, a few tweaks in the output description where I felt it was
a bit confusing- @gregsdennis let me know if these are wrong or if
you feel they're a net negative.

[gregsdennis]

This looks fine to me.

[handrews]

@epicfaace if you have a moment to take a look I'd welcome you're feedback on this PR.

[epicfaace]

Seems like the spec is moving towards defining rules for handling annotations in overlapping subschemas (as this paragraph is removed, and the wording in readOnly and writeOnly show), which is good.

[epicfaace]

Thanks for pointing me to this. The same logic you mentioned about defaults in #786 (and which is discussed in 7.6.1.1) could be used to argue against, however, the guidance added in this PR about how to handle overlapping annotations, such as:

        <section title='"readOnly" and "writeOnly"'>
            <t>
                The value of these keywords MUST be a boolean.  When multiple occurrences
                of these keywords are applicable to a single sub-instance, the resulting
                behavior SHOULD be as for a true value if any occurrence specifies a true value,
                and SHOULD be as for a false value otherwise.
            </t>

(For example, what if an implementor would prefer that the value of readOnly would only apply to the most specific subschema? or least specific?)

I'd prefer that the schema be explicit in these cases, as the PR does. My question is this: If it's able to be explicit about handling attributes such as readOnly / writeOnly, then why not defaults as well?

[handrews]

@epicfaace for readOnly and writeOnly there is a pretty strong consensus on appropriate behavior. We recommend this with the RFC 2119 term SHOULD to indicate that this behavior is expected to be common, and those who might take advantage of common behavior for interoperability should use this behavior.

However, SHOULD is not MUST. Application wishing to define alternate behavior for these keywords can still do so without contradicting the specification at all. SHOULD is a strong recommendation, but not a requirement.

Over the course of numerous years on this project, nothing remotely resembling a consensus around default has ever emerged. We have been unable to even get an agreement on whether the value of default ought to be valid against the schema in some way (this is more complex than it sounds and I'm not going to get into it- you can search issues, particularly closed issues, if you really want to slog through it). examples is similar, although for controversy no annotation comes close to the arguments and attitudes around default.

title and description are not really controversial, but at the same time, various people have requested diametrically opposed behaviors, all for reasonable reasons. So we do not take a position.

The goal here is to provide the appropriate amount of guidance for a given keyword, not to provide a one-size-fits-all approach to keyword definitions. Some keywords are helped by a recommendation (but you'll note that I weakened them from MUST to SHOULD specifically to ensure that all annotations have that freedom to be used differently). But some definitely are not.