Don't search drafts: Closes bug #713890

This avoids the constant resorting when replying to a conversation in
the search folder.  It also avoids the problems with the inline composer
in this state.
Separate composer widget from composer window

In anticipation of inline composition, we need the composer widget to be
separate from the window in which it lives.  We introduce a new
interface, ComposerContainer, that the thing that holds to
ComposerWidget must implement.

Separate composer widget from composer window

In anticipation of inline composition, we need the composer widget to be
separate from the window in which it lives.  We introduce a new
interface, ComposerContainer, that the thing that holds to
ComposerWidget must implement.

Basic inline composition

Many of the details don't work, or don't work well, but the basics are
in place.

Allow only a single inline composition at a time

With this, we introduce a dialog when you would try to add another.  We
also use this when changing the selected conversation with a composer
open.

Compose new messages inline, with no conversation selected

Hook up composer accelerators only when focus is in composer editor

It would be nice to only activate these accelerators when the composer
has focus generally, but that doesn't seem to be easy to detect.

Only disconnect accelerators if they're connected

Maintain focus when composer is popped out

The selection isn't, though.

Fix Tab focus for embedded composer

There are two things that needed to be fixed: The tab key doesn't
usually advance focus for embedded widgets (huh?), so we handle tab
presses by hand for ComposerWidgets.  Also, the EmailEntrys do their own
tab handling, which needs to know about the composer widget, not the
toplevel widget in the embedded case.

Remove close() from ComposerContainer interface

I don't think it was actually doing anything, and it conflicts with the new close() method of Gtk.Window.
Switch to using an overlay instead of a plugin for inline composer

This takes care of displaying it correctly, but we still need to handle
closing and destroying the composer properly.
Make ComposerWidget.should_close() return enum describing state
Use a new ComposerEmbed for each inline composer

I think this will make it easier to destroy the ComposerWidgets at the
right time.
Make composers close properly

For some reason, overriding the destroy handler causes reference errors
and multiple destructions.  So don't do that -- connect to the destroy
signal instead.
Don't prompt on delete_event if in the process of closing
Make widget live inside borders of containing div
Fix scrolling and resizing of webview in overlay

The webview doesn't properly shrink down unless the overlay implements
Scrollable.  But this keeps the overlaid widgets from scrolling with the
webview, so we adjust their position based on the location of the
scrollbars.
Remove sensitivity setting from make_gui_insensitive

They're not needed now that this hides the widget.
Undo special tab handling in composer (6e89dff8)

This isn't needed with the overlay.
Present the main window when presenting the embed
Use container alias instead of cast of composer parent
Close composers correctly during exit
Allow multiple inline composers

Replying to a message that already has a composer open will result in
that composer refocusing.  It should also adjust the Reply/Reply
All/Forward status, but that's still to come.

When switching away from a conversation with inline composers, the only
option is to cancel the operation or discard all compositions.  This
will be fixed by adding automatic saving of drafts in this case.
Move detach button to bottom of compose widget

Also, remove the embed toolbar at the top.

Note that the focus is stolen by the detach button when it's clicked, so
we can't re-establish it in the window.  Instead, we use the existing
set_focus() method to put in a (hopefully) appropriate place.
Compact header for inline replies
Don't show_all widget in ComposerContainers

We're adjusting visibility of various elements by hand, so it's better
if we don't adjust their visibility as part of the detach process.  We
keep it general in case some composers start windowed in the future.
Hide attachment widgets when no attachments

This saves a bit of space.
Don't focus on a detached composer instead of creating a new one