Define a FORMAT_N macro and use it wherever a python int needs to be built from a Py_ssize_t variable

Most likely this is not the only 'i' -> 'n' fix required.

o See http://www.python.org/dev/peps/pep-0353/ for details.

update for r94905: the proxy for `__iter__` must not rely on the object to have an `__iter__` itself, but also support fall-back iteration via `__getitem__` (this fixes https://bugs.launchpad.net/zope2/+bug/360761)

the package itself and make it a doctest.

http://www.zope.org/Documentation/Books/ZDG/current/Acquisition.stx

Clenaup

* Updated svn externals to include Zope 3.2 (currently the Zope3 trunk);
  that includes two new top-level packages, pytz and zodbcode, as well as
  the following new zope.* packages:
  - zope.deprecation
  - zope.dottedname
  - zope.formlib
  - zope.index
  - zope.testbrowser

* Moved to a zpkgutils-based build system, as the Zope 3.2 extension modules
  require to be built with it. If everything goes ahead as planned, the release
  tarball will also be built with zpkgutils (some work has also been done in
  that direction).

* Upgraded Five to the 1.3b release (released today) which is a Zope 3.2-compatible
  version of Five 1.2b (also released today). Biggest implication of this on the
  Zope 2 trunk is that the event work by Florent Guillaume has been folded back
  into the Zope 2 core, i.e. the OFS package.

* A few fixes to the Zope 2 PageTemplate/TAL/TALES implementation to work with the
  new immutable i18n Messages available since Zope 3.1+ (and standard in Zope 3.2).

      - Collector #1879: applied patch by Dieter Maurer to fix a bug in 
        ac_aquire() ignoring the default argument

- added some basic conformance tests

Note that this is just a first step:
- there are still some z2 interfaces that are not bridged to z3 interfaces
- the bridging introduces a dependency on Five, non-dynamic z3 interfaces might be more suitable (but add redundant code)
- 'implements' declarations are not complete
- many interfaces have unresolved XXX coments