The JSON codec will now check for a Nullable hint on the schema it is
parsing and not immediately parse fields as None if present. Note that
getting this to work with a new Nullable type does require adjusting
the code checking whether a Schema is for an Option a little so that it
can also include bijections from an option type.

This involves totally reworking the Field.Modifier logic, as the
addition of Nullable makes the number of cases too complex to keep track
of in an enum alone: the modifier logic now depends on
* whether there is a @required annotation present
* whether there is a @nullable annotation present
* whether there is a default value present, and (for nullable) whether
this value is null or a concrete value

making for a total of ten theoretical cases resulting in four possible
types in the Scala code. We model this in a case class and attempt to
shift some of the logic, such as ordering or working out the wrapped
type, to the class itself in order to avoid other parts of the code
needing to work with its internals.

There is a mild tension here: on the one hand, we really want to test
all the edge cases of different field modifier combinations to make sure
the generation code works as wel expect. On the other, these combinations
generally have only an extremely limited use or are just overly convoluted
ways to specify the default behaviour, and so they shouldn't be in the
sample specs people use to check usage. We handle this by providing two
test cases: Patchable, which handles the merge patch behaviour this whole
change is meant to support, and PatchableEdgeCases which is explicitly
described as only there for testing purposes.

???

Co-authored-by: Olivier Mélois <baccata64@gmail.com>

The error message rendering code for custom error message fields is
different for every type modification and also for custom vs primitive
types - we add a test case for every combination to be absolutely sure
they're being rendered correctly.

This reverts commit 8edf430.

Although technically the FieldTN representations aren't correct,
this part of the code should never use the @nullable annotation and
it's considered acceptable to leave as is.

This does not include every type class satisfied by Option but just the
ones we think are most likely to be needed by a consumer.

We refactor foreachUnlessDefault so the logic is not duplicated across
two methods, and add some tests to confirm that it works as expected on
a nullable field.

Including tests to make sure all traits and schemas behave as expected -
this does unfortunately require trying to figure out whether a schema is
Nullable at runtime, which is an awkward process.

Not 100% sure why this compiled locally, but it looks like this should
fix it?

It's acceptable for fields with a default value to be wrapped in Option
in the dynamically generated code, and trying to align it with the
static codegen behaviour is causing problems in the compliance tests.
We remove that change and any tests that relied on it.

Apparently 2.13 is more picky about line length for scalafmt than the
other Scala versions, and I hadn't formatted the test files right - this
should fix it.

…values.md

Co-authored-by: Olivier Mélois <baccata64@gmail.com>