Make the constraint types read as what they constrain

[LahaLuhem]

Closes #70, whose geography half shipped in #71.

Twelve types now implement their representation, so a constrained value reads as the primitive it
constrains and needs no .value: implements int on Digit, NaturalNumber, Uint and the five
UintN; implements double on Probability; implements String on AsciiChar, AsciiLetters
and AsciiAlphanumerics, with AsciiAlphanumeric and AsciiLetter inheriting it through the
narrowing lattice. Nothing unconstrained can be written into one, and digit + 1 stays a plain
int, so arithmetic cannot re-enter the type.

Additive, not breaking. The whole workspace analysed clean and all ten suites passed with no
changes outside minted_constraints. The one way it reaches a consumer is inference: [digit, 7]
moves from List<Object> to List<int>, which is why it is labelled sem-change rather than
sem-add. A minor is enough when this releases.

Four types opt out, each saying why in its own docs. Percentage holds 15 for fifteen
percent, so percentage * 200 would compute 3000 while reading as fifteen percent of 200.
Char, Letter and Letters guarantee characters where length counts code units, measured at
2 for one emoji and for one astral letter. The five Ascii* types escape that because code units
and characters coincide there, which does leave AsciiChar a String while its supertype Char is
not: accepted deliberately, as the price of not letting length lie.

Digits was never in scope, being a final class extends Iterable<Digit> rather than an extension
type. Rationale in APPENDIX.md#constraint-types, and a new transparent_representation_test.dart
carries the posture as one cross-cutting feature instead of a scenario in twelve files.