Pretty-printing of decoding failure history

From gitter: https://gitter.im/travisbrown/circe?at=56b1d0786b6468374a0b2b7c

Consider the following example:

scala> val json = parse("""[1, 2, "hello", 4, "world", 6]""").getOrElse(Json.empty)
scala> Decoder[List[Int]].apply(json.hcursor)
res5: io.circe.Decoder.Result[List[Int]] = Left(io.circe.DecodingFailure: Int: El(MoveRight,true),El(MoveRight,true),El(DownArray,true))

This part might be hard to parse for a human eye:

io.circe.DecodingFailure: Int: El(MoveRight,true),El(MoveRight,true),El(DownArray,true)

I guess we could improve the error message by reversing a history, making it a bit more visual, and maybe adding the element we failed to parse. Something along these lines:

[↴ array]
  →|→ × Failed to decode hello as Int

I’m not sure about arrow symbols though (on github they are very tiny), so maybe just printing

[down array]
  [right], [right] × Failed to decode hello as Int

[artempyanykh]

I see that CursorOp already has Show instance defined, and string representations of operators are already pretty visual there.

@tobias-johansson in his PR:

1. collapsed array traversals which is very reasonable since you hardly ever want to see 27 arrows on the screen -> instead of [27], and
2. changed the repr. of downField from --\\(field)" to .field.

These 2 things probably covers 80% of use-cases. For other Ops it just fallbacks to the already defined Show. Which gives us pretty much what I wanted to do minus a couple extra line-breaks 😃

@travisbrown do you think that going for the original output format is still relevant (comparing them side by side)?

[↴ array]
  →|→|→|→|→|→|→|→|→|→|→|→ × Int
// and
Decoding Failure at [12]: Int

From https://github.com/travisbrown/circe/pull/222#issuecomment-194017772,

DecodingFailure at .bar.baz.qux.a: String

looks really nice! What might be cool though is adding a current focus to the error message so it gives a bit more context

DecodingFailure at .bar.baz.qux.a: decoding 10 as String

[travisbrown]

Quoting myself from Gitter:

@tobias-johansson That sounds like reasonable output for Show[DecodingFailure]. I think it’d make sense to have the visualization that @ArtemPyanykh describes in #188 be available as something like a draw method on DecodingFailure, while the Show instance gives the more compact representation you describe.

So while #222 is merged, I think we should leave this issue open for the original more visual output proposed by @ArtemPyanykh.