Two IMAP tries: fix SEGV and useless loads..

Two IMAP tries: fix SEGV and useless loads..

For one, try to fix a segmentation fault that already caused me to
report at the OpenSSL list in ~november 2013, but i already stated
that i think it's our fault:

  ?1[sdn_gm imaps://sdaoden@XXXXXXXXXXXXXX]? newmail
  >>> T88 NOOP
  IMAP: error:00000000:lib(0):func(0):reason(0)

So this thing is dead.

  ?1[sdn_gm imaps://sdaoden@XXXXXXXXXXXXXX]? xi
  >>> T89 UID STORE 132181 +FLAGS (\Seen)
  IMAP write error: error:00000000:lib(0):func(0):reason(0)
  >>> T90 UID STORE 132181 +FLAGS (\Deleted)
  IMAP write error: Bad file descriptor
  ...

Trying to connect again unfortunately walks the entire list (it's
such a crap...)..

  ...
  >>> T108 UID STORE 132190 +FLAGS (\Deleted)
  IMAP write error: Bad file descriptor
  >>> T109 CLOSE
  IMAP write error: Bad file descriptor

  NYD: program dying due to signal 11:
  ...
  = [ 8] imap_preauth              imap.c:829
  > [ 9] imap_answer               imap.c:407
  > [10] sgetline                  fio.c:1407
  > [11] sclose                    fio.c:1108
  > [12] imap_timer_off            imap.c:561
  > [13] safe_signal               auxlily.c:247
  < [13] safe_signal               auxlily.c:256
  < [12] imap_timer_off            imap.c:566
  Segmentation fault

It crashes in the OpenSSL library, but it's likely that this
happens because a ressource is accessed that is gone.
Question is -- why is it gone, we didn't give it back via
sclose()!

imap.c tries to reuse a yet not disconnected "session" (i wouldn't
do it like that), and it only checks wether the descriptor is
still set -- extend this to check wether the last read failed,
too.
And also try to be more "atomic" in sclose(), this codebase jumps
like grazy and who knows what happens in this can of worms.  ,)

While here, don't fetch headers of invisible messages.