Wip/fix serialized value

[jsuereth]

Review by @havocp / @eed3si9n

Note: this is but one minor step in the process of getting to a better Serialized Value. Primary outcomes here:

1. Avoid serializing/parsing json strings like 30 times in their lifecycles
   • For this we altered the JSONPickle class directly
2. Expose what we need in SerializedValue and try to hide JsonValue (not succesful, but a start)
3. Remove the need for json4s native parser. Instead we use Jawn and a hand-written toString implementation for now. This can help avoid the re-ordering issues we saw before.

Again this is just a step in the right direction, not a full cleanup. However, I'd like to move from working state to working state, hence the intermediate PR.

[havocp]

Looks like a good improvement, LGTM.

Looking forward -

The separation between SerializedValue and JsonValue was based on the thought that sbt internals might use JsonValue and plugins/activator wouldn't need to know about JSON at all. But when I ported Activator that turned out to be pretty false, Activator needs JSON. Also I think we use JSON heavily in our test suite and plugin test suites also would need it.

Where I think we might end up later:

• delete JsonValue and just have SerializedValue
• SerializedValue works essentially like the commented-out LazyValue
• SerializedValue has methods to get a JSON string and to get a binary blob (when we have binary)
• SerializedValue companion object has methods to create SerializedValue from JSON or binary blob
• SerializedValue is lazy and may only store the original representation we created it from; if we add in-process SbtClient, if the SerializedValue is created from a picklee it may never serialize at all in-process. For Activator, it may read JSON off the wire and never deserialize it, just throw it back down to JS.
• SerializedValue could cache, or not, the JSON and binary versions, if we want, so once someone renders the JSON once we don't have to do the work again
• AST / jawn / json4s are all private implementation details; public API is just JSON string
• (un)pickler is for SerializedValue and we have custom code for each of our two formats (JSON and binary) allowing us to cleanly embed recursive serializations

Just a first draft idea.

[jsuereth]

I like the suggestions. A good path to walk down, IMHO.

I do like consolidating on SerialziedValue + SPickler/Unpickler for defingin protocols, while we hide details of JSON/Binary formats behind it. as @eed3si9n would be found of, we can avoid defining binary until we have pragmatic evidence it's needed.

[jsuereth]

@havocp / @eed3si9n ready for a second review if you want.