Add support for RFCs 5530 and 6855.

[arnt]

5530 (ENABLE) lets a client tell the server which extensions it would like to use, and lets the server tell the client which extensions is has enabled. Most IMAP extensions don't need to be enabled, but UTF8=ACCEPT does.

6855 (UTF8=ACCEPT) requires three things of clients:

1. The client uses ENABLE (added with tests)
2. The client accepts UTF8 strings (worked already, this adds testing)
3. The client cannot use certain SEARCH syntax (tb already did not)

6855 also allows some optimisations that this change does not contain:

1. A client can send UTF8 quoted-strings instead of some literals
2. A client can send UTF8 folder names instead of mUTF7

This change doesn't do either of those, because they add complexity (and unit tests) but no functionality. Some IMAP commands become three or seven or even ten bytes smaller. Who cares?

RFC 6855 differs modestly from its replacement, currently in the RFC-editor's queue. This implementation sides with the newer RFC when there's any difference.

This commit contains a couple of unit tests that do nothing right now, they merely guard against possible future breakage.

[cketti]

We need to make sure mailbox names are properly decoded.

My understanding of RFC 6855 is that LIST responses won't use the modified UTF-7 encoding for mailbox names when UTF8=ACCEPT is enabled. Is that correct?

The RFC text reads ambiguous to me (emphasis mine):

The "UTF8=ACCEPT" capability indicates that the server supports the ability to open mailboxes containing internationalized messages with the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8 responses to the "LIST" and "LSUB" commands.

That makes it sound like the server can use mUTF-7 or UTF-8 and the client has to deal with it. However, I don't see how a client could distinguish a mUTF-7 encoded string from a UTF-8-encoded string that happens to also be a valid, non-trivial mUTF-7 encoding.
Example:
"A &- B" when mUTF-7-encoded decodes to "A & B". However, when UTF-8-encoded decodes to "A &- B".

[arnt]

Excellent point. I don't think that was raised at all during the work on 653x/685x. I think it warrants a late change to 6855bis... I'll try to make the document conform to the majority of client code.