Senseful "OFS.SimpleItem.Item_w__name__.id" definition

[d-maurer]

Override id in OFS.SimpleItem.Item_w__name__ to avoid bugs by use of deprecated direct id access (--> #903 ).

In ancient days, all Zope objects had an id attribute. With the advent of Zope 3 technologies, __name__ seemed a better name for the name/id of a Zope object: direct id access was deprecated in favor of getId() and getId was defined to switch between id and __name__, as necessary. For backward compatibility __name__ was defined as alias for id, overridable on the instance level. This allowed for a graceful migration from the old id to the new __name__ use in the context of existing Zope object without __name__ but with id. However, newly created Item_w__name__ instances had a wrong id: for them, the deprecated direct access to id led to bugs (e.g. #903 ).

This PR defines Item_w__name__.id as follows:

• if the instance has instance attribute id, it is used (this handles the case of an old Zope object still using id in place of __name__)
• else if the instance has instance attribute __name__, its getId() it called; the precondition is necessary to avoid an infinite recursion (as __name__ is otherwise defined referring to id)
• else "" is used as id

This definition is not perfect: it fails for example,

• should a derived class decide to implement __name__ not via an instance attribute
• for objects with both id and __name__; for them obj.id could be different from obj.getId(). Such a case could result from the copying or renaming of an old Zope object (with id, without __name__).

However, if seems considerable better then the current state.

This PR would fix #903; however, it is not the best fix possible. This PR tries to avoid problems with the deprecated direct id access in general, not particularly for #903.