[PATCH 0 of 4] mail: encode parts not containing patches for readability

[Christian Ebert]

This patch series encodes mail parts that do not contain patches.

Patch data is left alone, sent in (fake) ascii. But as a first
step this allows us to make senders, recipients, subjects, series
descriptions that contain non-ascii text readable.

headers: subject, senders, recipients
body:
- messages sent by "hg notify"
- description text part for "hg email --attach"

Introduce new [email] charsets config.
Default:
us-ascii, util._fallbackencoding, util._encoding, utf-8 (if not
in first 3).
The default charsets do not need to be set explicitly, unless you
want to force another order.

Recommended explicit configuration (in most cases the default
is sufficient):

[email]
# for westerners
charsets = iso-8859-1, iso-8859-15, windows-1252
# other examples:
# iso-8859-1, iso-8859-15, windows-1252, iso-8859-2, windows-1250
# iso-8859-1, iso-8859-15, windows-1252, iso-8859-2, windows-1250, iso-2022-jp, iso-2022-jp-ms

(idea stolen from Mutt)

For headers and message parts that do not contain patches the
convert function cycles through charsets in descending order
to try a successful conversion.

Both $HGENCODING and util._fallbackencoding are tried for input.

As last resort the conversion falls back to fake ascii (ie. the
current behaviour).

New functions in mail module:
_charsets
_encode
headencode
addressencode
mimeencode

The patch queue (plus an attempt to fix issue#814 for patches in
pure utf) is also available at
<http://www.blacktrash.org/hg/hg-mail-mq/>

Crew repo with queue on top at
<http://www.blacktrash.org/hg/hg-crew-mq/>

c