[l10n] Updated Italian translation.
IMAPX: Buffer a full response line before parsing.

CamelIMAPXInputStream (and CamelIMAPXStream in older releases) was
trying to immediately parse whatever data it got from a read() call.

The problem is sometimes an IMAP response line can be split across
multiple Ethernet packets.

This confuses the parser into thinking it's reached the end of input,
and triggers an error and subsequent disconnect from the IMAP server.

We had a case of this recently from a user with a large number of
mailboxes -- enough that one of the LIST responses got split across
multiple Ethernet packets.

This commit attempts to passively buffer incoming data from the IMAP
socket until a full response line is detected, and only then is the
buffered response line parsed.

Note that response line detection is pretty primitive, and literals
containing CRLF sequences can trick it.  Therefore I'm leaving the
imapx_input_stream_fill() logic in place during tokenization until
we can replace our ad-hoc lexer with something more sophisticated
like Flex.
Revert "IMAPX: Buffer a full response line before parsing."

This reverts commit e8015389e09cfa33606da55d1e4a23f973d777d1.

Revert due to regressions on the first folder synchronization, which
ends with various errors, I spot "uid not integer" and "expected ')'"
errors. Reverting the change makes this work reliably again.
libedataserver: Make ECategories thread safe

Previously it was not, and could potentially be used from multiple
threads simultaneously (e.g. the main UI thread, plus a contacts backend
thread).

Introduce a static global lock on the categories variables, which
prevents most race conditions. Two functions are inherently unsafe, due
to returning pointers to internal data structures. These functions have
been deprecated and replacements introduced.

https://bugzilla.gnome.org/show_bug.cgi?id=727137
doap: update URLs
Add e_contact_get_attributes_set() for changes in bug #340075
CamelIMAPXServer not shut down properly on network outage

Even the CamelIMAPXStore had the server removed from its references,
the instance had been still alive in the background, when the network
changed and the destination host was unreachable.