There are a lot of places in the code where we rescue any error, at all.
That's quite dangerous, as it could conceal bugs.

I've changed it so that we always specify which error class we want to
catch. Mostly it's been a minor change, but there are two API changes:

* When it comes to loading data I've had to introduce an explicit list
  of protocols which we can load json over (otherwise it's possible to
  have a uri with a scheme that makes no sense - it'd still be a valid
  uri but loading from it is impossible). I've used the list of
  protocols that addressable recognizes for now.
* No matter what JSON parser you use, we now always raise a
  JSON::Schema::JsonParseError. Without doing this it would be tricky to
  handle parser errors identically, for all parsers (the other option
  would be to catch a long list of potential parse errors, but this
  seems more sensible).

Test all versions in test_custom_format

Update README.textile to fix schema validation example

Only rescue errors explicitly

Addressible's URI parsing shows up at the top of the profiler for our use case.

This patch adds a cache to JSON::Util::URI.normalized_uri, to trade CPU time for memory.

There are other expensive Addressible methods that should be cached elsewhere.

benchmark: https://github.com/mjc/json-schema-perf

MRI 2.2.2 before: 825.363  (± 6.2%) i/s
MRI 2.2.2 after:  1.436k (± 4.5%) i/s

1.74x faster

JRuby 1.7.20 before: 1.445k (± 2.5%) i/s
JRuby 1.7.20 after: 2.272k (± 6.1%) i/s

1.57x faster

Addressable::URI#fragment= triggers a revalidation of the URL, which is
super slow.  Don't do this when it isn't necessary.

Hopefully this will make it easier to change in future

For the unused variable `validator`

Remove ruby warnings

Redux: speed up JSON::Validator.validate