Added version-checking infrastructure for JSON serialization.
Fixes change status response to be numeric in jsonp metadata.
Allow symmetric representation of query string parameters as url-encoded string in a query string parameter.

(previously, woodchucks couldn't chuck wood)
Merge remote-tracking branch 'derek/master'
Merge remote-tracking branch 'jdegoes/master' into topic/versioned_json
Added tests around versioned serialization and deserialization.
Refactor Accept header handling for safer code paths
Rename of isApplicableTo to better reflect meaning
Merge remote-tracking branch 'derek/topic/accept_refix'
Merge remote-tracking branch 'jdegoes/master'
Add spec for produce Accept header verification
Add failFast option to AsyncParser.

Previously, an AsyncParser would try to accumulate as many parse
errors as possible using a newline-based error recovery strategy.
This change introduces a failFast Boolean constructor parameter.

When true, an async parsing result will return at most one error,
and no further parsing attempt will be made. When false, the
previous behavior will be used.

Note that the error-recovery is only intended to help users quickly
diagnose and fix bad JSON. The results when using error-recovery
are not well-defined unless users delimit their records with
literal newlines (and do not use literal newlines anywhere else).
Merge remote-tracking branch 'eo/topic/async-failfast'

Conflicts:
	json/src/main/scala/blueeyes/json/JParser.scala
Updated to latest scalaz-seven RC
Merge branch 'topic/jsonp_query_params'
Made lifting of extractors and decomposers to versioned instances use the PML pattern.
scalaz 7.0.0 final
Fix HttpException status line overflow

Previously, error responses generated by HttpException could
overflow the maximum HTTP line length because error messages
were being written into the status line. This change modifies
error handling to always use Content-Type: text/plain for
error responses generated as a result of HttpExceptions (and
other sorts of exceptions) thrown during request processing.

It is important to note that we have to use text/plain since at
the point of handling, no semantic information about the type of
the response is available. So, HttpException should *only* ever
be used for fatal errors that are not part of the defined API
for a given service.
DispatchError should not wrap an HttpException, since it should never be handled through the exception channel.
Merge branch 'topic/accept_refix'