More consistent concept of schema resources

[handrews]

[EDIT: I am going to do a revision of this attempting to keep the nice "schema resource" concept and facilitate the bundling use case without needing the $ref schema value. There are many things about the approach in this PR (788) that I like, but having sorted out more details I may have one more option for comparison.]

Fixes #779.

To me, this is essentially part of #780. Where we end up with
here is much more sensible and consistent, with fewer weird caveats.
It acknowledges a use case that I have seen and used often, while
making clear that many "dereferencing" cases, while common and
potentially workable depending on what you're doing, are in fact
likely to break things.

This further clarifies the schema resource concept and
how it is used. In particular, schema resources are
crucial to determining when it is safe to embed a
reference target into its referring schema.

This also requires allowing "$ref" to take a schema value.

The bundling use case should be more clear given this
guidance. While many reference target embedding transformations
are likely to break things and are therefor to be discouraged,
when framed in terms of schema resources a clear use case emerges.

This also relaxes a restriction on "$schema" that has no functional
impact but avoids requiring implementations to detect and handle
a rather complex case (embedding schema resources with different
"$schema" values). And also means that embedding can work without
having to change the embedded value by removing the "$schema"
keyword.

[handrews]

I'm going to take this down in favor of another approach. May revive if that doesn't work.