Make JObject and JArray immutable

Currently (and historically) JObject and JArray are mutable. They are case classes wrapping mutable data structures.

@ijuma wisely points out that this is maybe not the best for folks who want to use long-lived JObject instances, and suggests it would be nice to make the types safer.

Here are some possible scenarios (from least to most safe):

(I) Types are constructed with mutable collections, and expose them via getters. This is the status quo.

(II) Types are still constructed with mutable collections, but don't expose them directly. Data is accessed via read-only methods, or by copying the underlying data into a new structure. Mostly safe, although a fiendish user could construct a JObject, hang onto the mutable map, and change it later. (The parser is guaranteed not to do this.) The downside here is that it becomes more expensive to use JObject and JArray as a scratchpad during parse/modify/save cycles. (This is probably not a big deal.)

(III) Provide a public constructor using an immutable map, and a private constructor used internally that uses mutable maps. This way, users can't play games with mutable data, and (assuming the parser doesn't do anything fishy) we are totally safe. The downside here is that the objects become more expensive to construct, or that we have to add different JObject types for the different backing structures.

(IV) Convert Jawn to use immutable data structures only, possibly using builders in the Parser. This solves the safety issues, but probably increases the memory footprint and might have other performance issues.

Personally I think I prefer (II), but I'm open to hearing other suggestions.

The issue names JObject, JArray, and the parser but no source files or tests; first locate their definitions and construction paths. Compare options (II)–(IV) against the parser's parse/modify/save cycle, then get a maintainer decision on the safety and performance trade-offs before defining completion criteria.