OOPIFs: Transitioning Get/Send...SavableResourceLinks away from RenderViewHost.

OOPIFs: Transitioning Get/Send...SavableResourceLinks away from RenderViewHost.

RenderView => RenderFrame
=========================

This CL replaces ViewMsg_GetAllSavableResourceLinksForCurrentPage and
ViewHostMsg_SendCurrentPageAllSavableResourceLinks IPC messages by their
frame-oriented equivalents: FrameMsg_GetSavableResourceLinks,
FrameHostMsg_SavableResourceLinksResponse and
FrameHostMsg_NonSavableResponse (last one is needed to distinguish
between 1) a non-savable frame and 2) a savable frame with no savable
resources underneath it).

URL uniqueness and referrers
============================

SavePackage creates only one SaveItem per unique URL to be saved.
This CL moves uniqueness checks that used to be done in
content/renderer/savable_resources.cc into
content/browser/download/save_package.cc

Having only one SaveItem per given URL means that the code has to pick a
single referrer out of multiple referrals made from the page to the
given URL.  This is true both for the old and new code.  There might be
a need to follow-up to make sure that this is a valid approach (i.e.
some servers might return different content for different referrers, but
the same URL).  I've opened crbug.com/528453 to track this.

Just as before, after this CL we also take care to first process savable
resource links (preferring their referrers) and only later process frame
urls.  OTOH, after this CL we do not prefer referrers appearing earlier
(when sychronously walking over all subframes), but instead prefer
referrers from renderer processes which reply first (which can be
somewhat random).

Racyness of URL / content changes
=================================

Page content can change (i.e. with changes trigerred by javascript) between the
time the user requests save-page-as and the time we ask renderers for savable
links and serialized content.  The old code tries to protect against this, by
1. Calling Stop() in WebContentsImpl::OnSavePage
2. Verifying in content/renderer/savable_resources.cc that |page_url|
   (top-level url of the page user wants to save) is the same as
   |main_page_gurl| (current top-level url of the page).
In case of (2), save-page-as is cancelled.

Note that the old behavior of cancelling save-page-as in case of content
changes means that saving frequently changing content (i.e. page that
self-refreshes every X seconds) will fail every now and then.  It seems
preferrable to continue save-page-as in this case (as it will give the user
files with some (maybe more recent than intended) content rather than fail
altogether (i.e. this is preferrable because this behavior can satisfy users
who are ok with more recent content, whereas the other behavior would fail to
satisfy any users).

Also note that (2) does not protect against changes in subframes - in this case
the new subframe url will not appear in "urls that have local copy" field of
ViewMsg_GetSerializedHtmlDataForCurrentPageWithLocalLinks message (and
therefore the saved html will not be truly "complete").

Because of the above, the current CL doesn't make any attempt to try to
enumerate and lock down URLs of frames in the "before" state and ensure that
the same URLs are processed during later stages of save-page-as (gathering
savable resource links [this CL] and serialization [later CLs]).

BUG=526786

Review URL: https://codereview.chromium.org/1308113008

Cr-Commit-Position: refs/heads/master@{#349809}