Fix test runs for optional dependencies

This has become a bit of a mammoth fix to what I thought was a minor problem!

Here's a rundown of what I've learned:

1. On travis, the builds that test json-schema with optional dependencies have not been running since we introduced minitest, because the minitest dependency was only defined in the main Gemfile (and so the optional test runs would still be using test unit, and wouldn't find any valid test classes in our /tests directory). If you look in travis, the optional builds have been running 0 tests.
2. When I fixed this (so that the optional test runs were executing correctly) a single test in the common test suite was failing but only with yajl and multi_json, and not for the main test suite, because with those parses json schema was interpreting "127.0" as a float, whereas by default (with the json gem) it was a string (and with a string, the tests pass).

yajl and multi_json are right - "127.0" should be a float.

What's happening in the json-schema parsing code right now, is that if a json text is passed in and it doesn't parse, then we leave it as a string (then validate that string). However, yajl/multi_json parse "127.0" without errors (and return a number for validation), whereas json-gem throws an error because it (incorrectly) thinks that is invalid json (and then json-schema just uses the original string).

So, my conclusion is that the way we're using json-gem is incorrect right now. But if we switch on quirks mode (which is what mutli_json and rails do) it will parse numbers correctly. So that's what I've done (as well as fixing the optional builds).

This doesn't fix the test failure, but at least all the builds are behaving in the same way. The real problem is in the common test suite (they should be using a string for that particular test, not a float). I'm going to fix the common test suite now, but the code in this PR should be correct.
The diff is a bit unfortunate - this method is actually returning `JSON::Schema.stringify(data)` at the end, which is what we want to do either with `parse_data` or without it. I could return early but I'd have to duplicate that line.