[I18n-sig] Changes to gettext.py for Python 2.3

[Barry Warsaw]

Hi I18n-ers,

I plan on checking in the following changes to the gettext.py module for
Python 2.3, based on feedback from the Zope and Mailman i18n work. 
Here's a summary of the changes, hopefully there aren't too many
controversies <wink>.  I'll update the tests and the docs at the same
time.

- Expose NullTranslations and GNUTranslations to __all__

- Set the default charset to iso-8859-1.  It used to be None, which
would cause problems with .ugettext() if the file had no charset
parameter.  Arguably, the po/mo file would be broken, but I still think
iso-8859-1 is a reasonable default.

- Add a "coerce" default argument to GNUTranslations's constructor.  The
reason for this is that in Zope, we want all msgids and msgstrs to be
Unicode.  For the latter, we could use .ugettext() but there isn't
currently a mechanism for Unicode-ifying msgids.

The plan then is that the charset parameter specifies the encoding for
both the msgids and msgstrs, and both are decoded to Unicode when read. 
For example, we might encode po files with utf-8. I think the GNU
gettext tools don't care.

Since this could potentially break code [*] that wants to use the
encoded interface .gettext(), the constructor flag is added, defaulting
to False.  Most code I suspect will want to set this to True and use
.ugettext().

- A few other minor changes from the Zope project, including asserting
that a zero-length msgid must have a Project-ID-Version header for it to
be counted as the metadata record.

-Barry

[*] I've come to the opinion that using anything other than Unicode
msgids and msgstrs just won't work well for Python, and thus you really
should be using the .ugettext() method everywhere.  It's also insane to
mix .gettext() and .ugettext(). In Zope, all human readable messages
will be Unicode strings internally, so we definitely want Unicode
msgids.