Add spec for produce Accept header verification
Accept and produce combinators are horribly mixing operations that they shouldn't.
Annihilated a major source of abstract-val NPE evil.
Added HTTP proxying service combinator.
Restored correct end-of-stream behavior for AsyncParser
Remove automatic transcoding from HttpService#~
Jsonp should allow asymmetrically typed services.
scalaz 7.0.0 final
Added convenience implicit finders for Decomposer and Extractor
Added convenience mapv method to Extractor to allow easier composition of extractors.
Made URI more user-friendly.
DispatchError should not wrap an HttpException, since it should never be handled through the exception channel.
Merge branch 'topic/accept_refix'
Merge remote-tracking branch 'jdegoes/master' into wip/combinator_single_responsibility

Conflicts:
	core/src/main/scala/blueeyes/core/service/HttpServerModule.scala
	core/src/main/scala/blueeyes/core/service/HttpServices.scala
	core/src/test/scala/blueeyes/core/service/HttpRequestHandlerCombinatorsSpec.scala
Fix major problems in the AsyncParser design.

The async parser was introduced to handle a very specific use case:
parsing a (whitespace delimited) stream of relatively small (<1M) JSON
objects. Its design, buffering strategy, and strategy for resuming
parsing were all based on this scenario. In scenarios where the user
wanted to use many small chunks to parse a much larger value (i.e. 60M)
parser performance would degrate horribly compared to the synchronous
(all-at-once) parser.

Furthermore, the error-recovery strategy was based around similar
assumptions, and was not reliable in general (without frim commitments
from the user about delimiters and escaping it is hard to see how it
could be).

This commit does several things:

 1. Fix the major performance problems seen when async parsing one
    large value. While this is still not an ideal situation,
    performance is now roughly on-par with the equivalent sync parser.

 2. Remove the error-recovery option for the AsyncParser. It didn't
    work reliably and was not being relied on by anyone.

 3. Create 3 different async parsing modes:

    a. Streaming: This is the existing behavior (returning a collection
       of whitespace-delimited JSON values).

    b. Json: This mode expects the input to be a single well-formed
       JSON value. In the future this should become the default
       behavior.

    c. Unwrapping: This mode is like (b) but if the JSON value is an
       array, the parser will instead parse the contents of the array
       as a stream and return those values, rather than the outer
       array.

    Mode (c) is especially exciting, since for situations where users
    need to parse very large arrays of values. Unlike the sync parser
    (or the async parser in modes (a) and (b)) unwrapping means that
    the parser itself does not need to accumulate and store all the
    parsed objects itself.

 4. The commit adds some additional tests and benchmarks to measure the
    performance of these parsers.

None of the synchronous parsers should be affected by these changes.
Merge branch 'master' into wip/combinator_single_responsibility

Conflicts:
	json/src/main/scala/blueeyes/json/AsyncParser.scala
	json/src/test/scala/blueeyes/json/JsonParserSpec.scala
functor composition for ResponseModifier
Refactor ByteChunk to use Array[Byte] not ByteBuffer.

Previously, ByteChunk was defined as:

  Either[ByteBuffer, StreamT[Future, ByteBuffer]].

This meant that users had to be *very* careful to avoid evaluating
ByteChunks in parallel, since the underlying ByteBuffer's position
fields are mutable and are changed by reads.

The new definition is:

  Either[Array[Byte], StreamT[Future, Array[Byte]]]

While the underlying data is itself mutable, the act of reading the
data will not modify the array. This should remove a whole class of
possible errors, and make it much easier to write correct request
combinators.
Get tests running and passing.
Added more logging to HttpClientXLightweb