Use lo_creat() instead of lo_create() when creating large objects without new_oid.

This enhances the compatibility with the pgpool-II replication middleware,
that doesn't support lo_create() calls.
Test methods reordered to improve readability
Added test to check rowcount behaves fine during named cursor iteration

Actually *it doesn't*: once we iterate the first itersize records, rowcount
is reset to zero. If we want to fix it we need an extra member in the
cursor.
Fixed rownumber for cursor subclasses during iterations

Regression introduced to fix ticket #80. Don't use fetchmany to get the
chunks of values. I did it that way because I was ending up into infinite
recursion calling __iter__ from __iter__: the solution has been the
"while 1: yield next()" idiom.
Fixed NamedTupleCursor rownumber during iteration.

The correction is similar to the other one for the other subclasses.

Also added tests for rowcount and rownumber during different fetch styles.
Just in case.
Ticket #100 closed

Note that rownumber is still broken for named cursors: it is reset to zero
when each itersize block is fetched.
Merge branch 'cursors-rownumber' into devel
Fixed exception testing on Python 3

...and so caught exceptions are local to the except suite in Py3.
(Lo sapevate? Sapevatelo!)
Fixed inet test that wasn't testing anything
register_uuid takes more iterables types as oids argument

Also added docs for the function parameters.
Added support for inet array
Added docs about how to create a generic array typecaster
Merge branch 'types-arrays' into devel
Check/set connection status at commit inside the critical section

Failing to do so was causing the issue reported in ticket #103. The issue
as reported was fixed when SET ISOLATION LEVEL was dropped, but the real
problem wasn't fixed.
Dropped redundant check on the status before rollback

The check is better done inside the critical section.
Update all links to PostgreSQL docs to the current version.

I also checked all links and anchors to make sure they're still valid.
Dropped test about close() on closed connection raising an exception

This seems unnecessary and has caused problems to a few. The DB-SIG seems
agreeing on the change:
http://mail.python.org/pipermail/db-sig/2011-October/005811.html
close() methods don't raise errors if called on closed objects
Merge branch 'close-idempotent' into devel
Merge branch 'gcc-python-plugin' into devel