Don't allow clients to traverse into superclass synthesized properties

via CollectObjCIvars.
 - In places where we need them, we should have the implementation and
   access the properties through it.

This is a fairly substantial functionality change: 
 1. @encode no longer encodes synthesized ivars, ever.

 2. The ivar layout bitmap no longer encodes information for
    synthesized ivars in superclasses. Well, actually I had already
    broken that, but it is intentional now.

We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.

Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.

I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.

llvm-svn: 70822