[Dev] New iterItems() convenience API

[Phillip J. Eby]

I've added getKind() and iterItems() classmethods to schema.Item, so that 
you can more easily get at kinds or do KindQueries.  For example, you can 
replace code like this:

        kind = "//parcels/osaf/contentmodel/mail/IMAPAccount"
        for item in ItemQuery.KindQuery().run([view.findPath(kind)]):
            if item.isActive and item.host and item.username:
                yield item

with this:

        for item in Mail.IMAPAccount.iterItems(view):
            if item.isActive and item.host and item.username:
                yield item

(Assuming, of course, that you've imported the Mail module.)

The iterItems() API takes a view, and an optional 'exact' keyword 
parameter.  Setting 'exact' to 'True' limits the query to finding only 
items with the exact same class, filtering out any subclass instances.  The 
default behavior (and what you usually want) is to include subclasses.

The new getKind() API is basically the same as the one available as 
ContentItem.getKind(), except that it does not rely on knowing myKindPath 
or any of that.  So, I am currently working on a patch that gets rid of 
ContentItem.getKind() (which will then be replaced via inheritance with 
schema.Item.getKind()) and all definitions and uses of the no-longer-needed 
myKindPath and myKindID variables.  As a result, new developers won't need 
to learn about these things in order to define and use a Chandler schema.

Indeed, our goal is to get rid of all hard-coded use of repository paths to 
access schema-defined items, so the patch I'm working on also replaces most 
existing uses of KindQuery with iterItems() calls.  (It should land 
sometime on Friday.)  I'll also be surveying the code for other hardcoded 
paths in order to see whether the schema API needs other convenience 
methods like iterItems() in order to avoid the need for using paths.