User model stacking

[Kevin Bourrillion]

This is kinda reading as...

* First we have 3 buckets
* But people ask if there could be just 2 buckets
* No, so let's have 5 buckets.

I don't understand why this is happening, but I take it back! I take back
what I said about 2 buckets!

I'm not sure what problem this is needed to solve.

~~

By the way, as we talk about this zero problem, these are the example cases
that go through my head: <draft, please help refine this>

(Type R) e.g. Rational, EmployeeId: the default value is illegal; can't
even construct it on purpose. Every method on it *should* call
`checkValid()` first. Might as well repurpose it as a pseudo-null. Bugs
could be prevented by some analogue of aftermarket nullness analysis.

(Type I) e.g. Instant: the default value is legal, but it's a bad default
value (while moderately guessable, it's arbitrary/meaningless). This makes
the strongest case for being reference-only. Or it has to add a `boolean
isValid` field (always set to true) to join Type R above.

(Type C) e.g. Complex: the default value is a decent choice -- guessable,
but probably not the identity of the *most* common reduction op (which I
would guess is multiplication).

(Type O) e.g. Optional, OptionalInt, UnsignedLong: the default value is the
best possible kind -- guessable, and the identity of the presumably most
common reduction operation.

For type I, we would probably ban nonempty array instance creation
expressions! This would force the arrays to be created by
`Collection.toArray()` or by new alternative value-capable versions of
`Arrays.fill()` and `Arrays.setAll()` which accept a size instead of a
premade array. Actually, if the new Arrays.fill() could short-circuit when
passed `TheType.default` then we might want to do this for types C and O
too; why not make users be explicit.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com