Expose extraneous fields in error in strict decoding

[travisbrown]

In some cases it can be necessary to know exactly what extraneous fields where encountered when using strict decoding, but currently the API here only indicates those fields in the DecodingFailure error message string (which is really the only thing we can do, given the Decoder and DecodingFailure API, which don't let us return additional structured information like this in the result of failure).

The change in this PR adds a new ExtrasDecoder API that includes a decodeStrict method (on the model of e.g. decodeAccumulating) that also returns a list of extraneous field keys in the case of failure.

I've added new deriveExtrasDecoder, etc. methods that return derived instances statically typed as ExtrasDecoder or ExtrasAsObjectCodec. (I've also included deriveExtrasEncoder for consistency, although it's currently identical to deriveConfiguredEncoder.) We could alternatively just have the derivedConfiguredDecoder methods return this subtype, but while that would be source-compatible, it would break binary compatibility (which probably doesn't matter much for a macro-oriented project like this, but still). In its current form this PR is verified by MiMa to be binary compatible with the 0.13.0 release.

@erwan What do you think?

[erwan]

So that would be a decoder that fails if there are additional fields in the json, that we're not using?

[travisbrown]

@erwan Yes, that part is already supported, via withStrictDecoding configuration. The issue is that it only tells you the extra fields in the error message string, while it's often useful to have them be programmatically available, which is what this part adds.

[travisbrown]

I'm not sure what's going on with the Scala.js failure on 2.12. I'll take a look tomorrow.

[erwan]

yes, sounds like a good idea to expose those fields in a more usable way than just the error string 👍

[travisbrown]

That should fix the build issue—I'll go ahead and publish this as an 0.13.1-M1 when green.