IMAP Gateway: implement search capability

RFC3501:

3.2.3. Searching

   IMAP SEARCH commands can become particularly troublesome (that is,
   slow) on mailboxes containing a large number of messages. So let's
   put a few things in perspective in that regard.

   The flag searches should be fast. The flag searches (ALL, [UN]SEEN,
   [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
   are known to be used by clients for the client's own use (for
   instance, some clients use "SEARCH UNSEEN" to find unseen mail and
   "SEARCH DELETED" to warn the user before expunging messages).

   Other searches, particularly the text searches (HEADER, TEXT, BODY)
   are initiated by the user, rather than by the client itself, and
   somewhat slower performance can be tolerated, since the user is aware
   that the search is being done (and is probably aware that it might be
   time-consuming). A smart server might use dynamic indexing to speed
   commonly used text searches.

...

   Another word about text searches: some servers, built on database
   back-ends with indexed search capabilities, may return search results
   that do not match the IMAP spec's "case-insensitive substring"
   requirements. While these servers are in violation of the protocol,
   there is little harm in the violation as long as the search results
   are used only in response to a user's request. Still, developers of
   such servers should be aware that they ARE violating the protocol,
   should think carefully about that behaviour, and must be certain that
   their servers respond accurately to the flag searches for the reasons
   outlined above.

   In addition, servers should support CHARSET UTF-8 [UTF-8] in
   searches.

http://tools.ietf.org/html/rfc2683

---------
 Any message sequence numbers in an argument to UID SEARCH
        are associated with messages prior to the effect of any
        untagged EXPUNGE returned by the UID SEARCH.

http://www.rfc-editor.org/errata_search.php?rfc=3501

-------------

      In all search keys that use strings, a message matches the key if
      the string is a substring of the associated text. The matching is
      case-insensitive. Note that the empty string is a substring; this
      is useful when doing a HEADER search.

http://www.rfc-editor.org/errata_search.php?rfc=3501

-------------

Section 6.4.4, page 54:
        old:
               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
               C: XXXXXX
               S: * SEARCH 43
               S: A284 OK SEARCH completed
        new:
               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
               S: + Ready for literal text
               C: XXXXXX
               S: * SEARCH 43
               S: A284 OK SEARCH completed

http://www.rfc-editor.org/errata_search.php?rfc=3501

----
Formal Syntax, Page 84:
        old:
CHAR8 = %x01-ff
                    ; any OCTET except NUL, %x00
        new:
CHAR8 = %x01-ff
                    ; any OCTET except NUL, %x00

charset = atom / quoted
-----

Formal Syntax, Page 89:
        old:
resp-text-code = "ALERT" /
                  "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
        new:
resp-text-code = "ALERT" /
                  "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
-----

Formal Syntax, Page 89:
        old:
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
        new:
search = "SEARCH" [SP "CHARSET" SP charset] 1*(SP search-key)
-----

Formal Syntax, Page 90:
        old:
sequence-set = (seq-number / seq-range) *("," sequence-set)
        new:
sequence-set = (seq-number / seq-range) ["," sequence-set]
-----

http://www.rfc-editor.org/errata_search.php?rfc=3501