Record Serialization - Update

[Brian Goetz]

Thanks Chris.  This looks sensible.  A few questions inline.

>    - The serial form of a record is it's state components. It is not
>      customizable (*).

Must the fields appear in the stream in the canonical order?  Or, are 
they serialized by name, and then we swizzle them back into the order 
desired by the canonical constructor?

>    - Serialization will ignore pretty much all of the magic methods, if
>      they appear in a record (**).

What about serialVersionUID?

What happens if the fields present are a superset, or subset, of the 
components in the canonical ctor?

>    - Record-like class to record migration is supported (and vice versa),
>      since the stream format is not changed.

So, if a class C migrates to a record R, the serialized fields are just 
fed to the canonical ctor.  Must serialVersionUID match?  Or maybe, if 
at deserialization time it's a record, we just ignore svuid?

> (**) we want to allow `writeReplace` as an escape hatch, in case for
> example, a non-serializable type ends up as a component in a
> serializable record, or maybe if one wants to replace the serializable
> record with a proxy that, say, refers to a singleton value, or similar.

This seems reasonable.