Add LIST RETURN functionality

SPECIAL-USE does not have to return special-use flags, but the
LIST RETURN syntax can force it, which we want.
Better IDLE state handling

OpenMailbox.org doesn't complete transactions when the IDLE state
is entered while commands are outstanding.  One thing I've considered
for a while is only issuing IDLE when no comands are outstanding,
as in some situations the connection state "thrashes" if commands
come in back-to-back.  This commit does just that, only entering
IDLE when no commands are outstanding.
Fix bug in reestablishment logic intro'd in commit 86f1854

One bug in that commit was that only one of two the two conditionals
for entering connection reestablishment was considered when
determining if the Folder should close.  This change now uses both
conditionals.  Without this, it's possible for the remote to fail
to open due to connection error and the Folder to remain open although
reestablishment doesn't occur because there's no remote folder to
establish with.
Further work fixing connection reestablishment logic

More testing of previous changes located two other problems that
this patch fixes.

First, if a connection reestablishment was attempted but the reconnect
failed initially (common if the server is simply unavailable, i.e.
recent Gmail outage) the reestablishment logic halts.  This patch
forces another attempt.

Second, the back-off delay that used to be present in the
conversation monitor (when it handled reestablishment) was missing
in the new code.  This adds it back.
Allow flag watching while synchronizing folder in background

Previously, synchronizing folders caused a jump in CPU, so work was
done to minimize activity.  Optimizations to folder normalization
has reduced the CPU load, so it's okay now to allow flag watching
while the background folder is open.

This is not a substitute for an architected solution: periodic
flag synchronization with folders, not merely when changes in contents
(additions/removals) are detected, but this helps some, especially
with high-traffic folders.
Reduce local delays when new message arrives

In particular, bug #713493 reports this, although this patch doesn't
appear to solve the problem entirely.  However, I have spotted
situations in the past where the Append replay operation caused local
operations to hang.  This is because Append was being treated as a
local operation when, in fact, it's first call is back to the server
to fetch UIDs of the new messages.  Hence, it should be treated as
a remote operation so local operations can run without delay.