Alternative to IdentityObject & ValueObject interfaces

[Dan Heidinga]

> As Dan points out, the main thing we give up by backing off from these interfaces is the static typing; we don't get to use `IdentityObject` as a parameter type, return type, or type bound.  And the only reason we've come up with so far to want that is a pretty lame one -- locking.

During our various discussions, we've also used `IdentityObject` and
`ValueObject` as constraints in the t-vars / parametric VM proposal to
address methods that are only partially applicable.  We've also talked
about using that as a signal to allow locking and other
identity-operations to compile inside generic code that we can
statically know won't have to deal with values.

Does giving up on having VO/IO in the type system change our
approaches to either the parametric vm future or identity operations
in generic code?  It sounds like we're willing to give up on the
second but I don't have a good sense of what this does to the
parametric VM.

--Dan