Resolution of schema handling issue

[Cantor, Scott]

Repeating what we agreed to on the dev call...

- let Spring be Spring (don't override loader/resolver)
- use versionless URLs to the schemas in our config files, tests, etc
- use spring.schemas to map those URLs to the classpath filename

In other words, today we have this:

schemaLocation="urn:mace:shibboleth:2.0:resolver
	classpath:/schema/shibboleth-2.0-attribute-resolver.xsd"

The new files will have this:

schemaLocation="urn:mace:shibboleth:2.0:resolver
	http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd"

And spring.schemas will have:

classpath\:/schema/shibboleth-2.0-attribute-resolver.xsd =
	schema/shibboleth-attribute-resolver.xsd
http\://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd =
	schema/shibboleth-attribute-resolver.xsd


(ignore the whitespace, that's just for email formatting)

We're essentially building a stable URL API for the schemas and just
"describing" that API in spring.schemas. The extra entry is needed to
maintain support for the schemaLocations in legacy configuration files.
Assuming that works, which it should. If it doesn't, we may have to adjust
this slightly by maintaining the old 2.0 filenames in the jars and just
map the new URL to that old name. One could argue that's even better since
it eliminates a second spring.schemas entry, but I think making a clean
break and having an explicit compatibility allowance via spring.schemas
seems better.

The only labor intensive, don't make me do it twice, step is changing
schemaLocation, and I think that much is impervious to the rest of the
decisions.

-- Scott