Should ObjCClass stay a subclass of type?

At the moment `ObjCClass` extends `ObjCInstance` and `type`. As far as I can tell, the fact that it extends `type` is not used or needed for anything at the moment. A metaclass don't need to subclass `type`, it's enough to have its constructor accept the signature of `type`'s constructor (name, bases, namespace).

It's also misleading, because users might expect to be able to define Python methods on Objective-C classes (by not decorating them with `@objc_method`). This is not possible at the moment, because instances of user-defined Objective-C classes are actually instances of `ObjCInstance`, and not of the user's `ObjCClass` subclass. We could theoretically support this though - similar to how an ObjC `NSArray` becomes a Python `ObjCListInstance`, we could make an ObjC `UserSubclass` become a Python `UserSubclass` too. (The logic in `ObjCInstance._select_mixin` would probably need to be optimized though, I don't think a chain of `isKindOfClass:` scales well.)

Start by reading the ObjCClass and ObjCInstance definitions, especially ObjCInstance._select_mixin, and compare the current metaclass behavior with type's constructor signature. Determine whether ObjCClass can stop subclassing type and whether user-defined Objective-C subclasses should preserve their Python class identity. Done means the design is resolved and covered by appropriate tests.

Written by the indexing model from the issue text.