doc-hidden CaseMappingData field

[Manishearth]

This is a followup from #2301. I added a public field there so that databake could work, noting that CaseMappingData doesn't apprear to have any invariants.

cc @iainireland can you verify that that is the case re: invariants?

Either way, it's probably nicer for this to be doc(hidden) until we know for sure. We can also write a nicer manual databake impl that uses a constructor function if preferred.

[iainireland]

CaseMappingData has invariants that are validated in CaseMappingInternals::validate:

1. If the exception bit is set, then the exception index must point to a valid exception header.
2. If the exception bit is not set, or if the exception has a Delta slot, then c + delta must be a valid character.

[Manishearth]

@iainireland right, but it is already possible to construct an invalid CaseMapping data via serde or ULE, it seems like this is one of those cases where the invariant is not enforced by the type, correct?

[iainireland]

Maybe it's more accurate to say that CaseMappingInternals has invariants. Any given u16 is a potentially valid payload for a CaseMappingData. There's no way for the type to validate itself. It can only be checked for validity in the context of the entire CaseMappingInternals. For example, it's valid for a CaseMappingData d to encode a large negative delta; it's not valid for the trie inside CaseMappingInternals to map characters smaller than that delta to d. Similarly, you can encode any exception index you like, but it has to correspond to a valid index in the associated CaseMappingExceptions data.

If that maps onto "doesn't have any invariants" for your purposes, then I confirm that CaseMappingData doesn't have invariants.