Alternative to IdentityObject & ValueObject interfaces

[Dan Heidinga]

(Sorry Dan, you're receiving this twice.  I accidentally sent it off list first)

> Here's another more stable encoding, though, that feels less fiddly to me than what I originally wrote:
>
> ACC_VALUE means "allows value object instances"
>
> ACC_IDENTITY means "allows identity object instances"
>
> If you set *both*, you're a "neither" class/interface. (That is, you allow both kinds of instances.)
>
> If you set *none*, you get the default/legacy behavior implicitly: classes are ACC_IDENTITY only, interfaces are ACC_IDENTITY & ACC_VALUE.
>

identity class F { }
abstract /* neither */ class N extends F { }
value class V extends N { }

This is clearly an illegal stacking of the bits as we can't have value
subclasses of identity objects.  We'll need to spec out rules about
super-class bits being "sticky" and overriding subclass bits if we
want to allow `N` to be loaded or add rules that make `N` illegal.

Apart from this - which isn't really different from dealing with
inheriting the VO/IO interfaces - I think your new proposed encoding
is better than my (not so) clever one.

--Dan