Adoption of throws, remove Result dependency

[zwaldowski]

This is it… the big one. This completes the triumvirate of Swift 2 PRs, starting with #48 and #53.

This is a big breaking change and should be considered very carefully for completeness, clarity, and documentation coverage.

• Introduces a new subscripting API that throws on error
  • All subscript methods take 0 or more "path elements" (String or Int) as varargs, so instead of let name: Result<String> = json["details"]["people"][0]["name"].string, you get let name: String = try json.string("details", "people", 0, "name").
  • Alternate versions that all take an @autoclosure or: () -> T, completing Add ability to fall-back to defaults for missing values #30 and superseding Fallback (or) #32.
  • Alternate versions that return an optional when a key is missing, completing Add ability to lift key-not-found errors into optionals #29.
  • Alternate versions that return an optional when a key is present but is a .Null.
• Moves to throws for deserializing, serializing, parsing, and encoding.
• Moves the act of deserializing JSON into the two JSON parsers to a protocol.
  • Gives JSONParser a public API.

TODO/Known issues:

• Update README.

[zwaldowski]

Updated to depend on #53.

[zwaldowski]

Rebased to resolve all dependencies.

[zwaldowski]

Further changes have been made to subscripting to reduce complexity and remove more code.

• String, Bool, Int, and Double now themselves conform to JSONDecodable.
• Exposes a decode(_:type:) family of subscripts that work for any JSONDecodable. For an implementer of JSONDecodable where your init(json:) is primarily assigning to stored properties, this means 99% of your code could go through decode(_:type:).
• Exposes a arrayOf(_:type:) family of subscripts that combine array(_:) and decode(_:type:).

Please give another glance over JSONSubscripting if already have.

[zwaldowski]

Updated to replace JSONPathType with a concrete JSON.PathFragment. This involves a little bit of funniness with literal convertibles (:car:) and default arguments, but testing against #59 yields a 15% performance increase to decoding.

[hitsvilleusa]

Why are you using try! and not just try? If the decodeString() throws, don't we want to propagate that error?

[zwaldowski]

Very good point. I think the change passes just happened at different times.

[zwaldowski]

Oh, it might also be that I was going to change the internal functions like decodeString() to return String instead of JSON. But that'll be later.

[hitsvilleusa]

This is one of the few things that I saw in all of this that I think is "wrong". As far as I can recall, most of the other suggestions are simply thoughts/suggestions/confusion.

If this should be changed, go ahead and make it, or I can if you're ok with that.

[zwaldowski]

Addressed.

[zwaldowski]

Updated to address comments as well as resolve mergability with its base branch.