GitLab

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774

Review-Url: https://codereview.chromium.org/2325893002
Cr-Commit-Position: refs/heads/master@{#417518}