Add JSONDeserializer for transforming NSData to JSON

[gfontenot]

This adds a failable initializer that wraps up the NSData -> AnyObject -> JSON transformation into a self contained package. Now all you need
to do is pass the NSData directly to JSON and you'll get an optional
JSON value back. That value can then be (conditionally) passed into a
decoder for parsing.

Open to comments here. Should this live somewhere other than this?

Fixes #68

[tonyd256]

I can see an argument for it not living here because technically Argo could decode anything that comes in a Swift/Objc object form.

In the future, if we look into changing the JSON enum name I would probably change the init to something like public init?(jsonData: NSData) so we could have other basic initializers.

I am ok with this though.

[gfontenot]

That's a good point. What about throwing this on a simple JSONDeserialization class that only does this?

[tonyd256]

Ya I think I like the idea of it being separate from this JSON enum ... I would be more into that

[gfontenot]

@tonyd256 Want to take another look? Also ping @thoughtbot/ios for thoughts on this?

[tonyd256]

I think this is better

[hyperspacemark]

Too early to yank this up to a Deserializer protocol?

[gfontenot]

probably. I think that's an easy enough refactor later on if we actually have real-world usage for parsing other sources of NSData

[hyperspacemark]

Fair. My thinking here is that it would at least indicate to consumers of this framework that they can implement additional deserializable types if they want to.

[gfontenot]

Fair point.

[hyperspacemark]

I just realized that we shouldn't be obscuring the ability to set reading options here. Consider a response that doesn't begin with an array or object. For instance...

response_date: 2015-03-04T12:43:20Z,
post: {
    id: 1
    title: "JSON Fragments Considered Harmful"
}

Attempting to parse this with NSJSONSerialization without specifying the NSJSONReadingOptionsAllowFragments option would return an error: The operation couldn’t be completed. (Cocoa error 3840.)" (JSON text did not start with array or object and option to allow fragments not set.)

To work around this, I suggest we overload deserialize(data:) -> JSON? with deserialize(data:allowFragments:) -> JSON?.

I'm pretty sure we can disregard the other reading options, .MutableContainers and .MutableLeaves but I could be convinced that we should add more overloads or a function that just takes an NSJSONReadingOptions if there's a really good use case for it.

[gfontenot]

@tonyd256 What do we think about this idea now that we have Decoded<T> and the global decode functions?

[gfontenot]

After discussing with @tonyd256 in meat space, we don't think this is super useful. Micromanaging the NSData deserialization doesn't seem worth it, and it puts us in a weird place where we have NSData -> JSON (skipping AnyObject), and AnyObject -> Decoded<T> (skipping JSON). Including JSON specific decode functions just to avoid NSJSONSerialization feels like over architecting. Instead, we want to improve Decoded so that it's easier to simply flatMap the AnyObject? value from NSJSONSerialization and get back T? or Decoded<T>

I've taken a stab at this in #96 and am closing this PR in favor of that one.