Design a strategy for documenting serialization packages

[jskeet]

As of 2.x, we're not tying our serialization packages (currently just NodaTime.Serialization.JsonNet, but I'm expecting to add NodaTime.Serialization.Protobuf - not sure whether that will start as 1.0 or be 2.0 from the get-go...) to the main NodaTime package versioning. There can be a NodaTime 2.1 without a corresponding NodaTime.Serialization.JsonNet release, or there could be 2.1 and 2.2 of NodaTime.Serialization.JsonNet without a corresponding NodaTime release.

We've currently moved the serialization code into its own repo. That may or may not prove to be a mistake. (Hopefully not...)

So how do we document the serialization projects?

• It probably makes sense to keep "unstable" in the API docs including the latest unreleased code from all packages
• It probably makes sense to keep NodaTime.Serialization.JsonNet in with 2.0.x as they really were released together
• What about for NodaTime 1.1? 1.4? Other serialization package releases?

[jskeet]

For 2.1, I think I'll just include the 2.0 serialization docs as we do for 2.0, to give us more time to work this out.

[jskeet]

Current plan:

• New "serialization" option under "current"
• Don't keep multiple versions, but potentially later on add the "available since..." annotation
• Remove the serialization docs from the main API docs

[jskeet]

This is now implemented, other than for issues #8 and #9.