ProtoObject and comparison for equality and ordering

[Andrei Alexandrescu]

OK! I finally remembered why we went with the design "any two 
ProtoObjects must be comparable". We should have a way to document this 
stuff, I'd internalized it so much I'd forgotten the reason.

It has to do with the way D implements built-in tables. They use 
indirect calls via TypeInfo classes that essentially require the 
existence of equality and hashing in class objects as virtual functions 
with fixed signatures.

So if we go with a statically-driven solution we lose hashtables keyed 
on any class not derived from Object. That would be awkward but 
hopefully acceptable until we have good containers (which are becoming 
possible only now with copy ctors and the upcoming __RefCounted type in 
druntime).

A possibility to bridge us is to create a wrapper struct:

struct HashKey(T) if(is(T == class)) {
     private T payload;
     bool opEquals(HashKey rhs) { ... }
     size_t toHash() { ... }
     alias payload this;
}

Inside the implementations introspection would be used to figure out how 
type T chose to implement comparison and hashing.

My thinking is, built-in hashtables are overdue for improvement anyway 
so keeping compatibility with them isn't awfully motivating.

Satisfactory or not?