WIP - Refactor programmatic downloads

NOT FOR COMMIT. This is a combination of a number of proposed CLs.

------------------------------------------------------------
WIP - Refactor programmatic downloads

Explicit downloads no longer need to pretend that they were initiated by
a renderer.

Introduce a UrlDownloader class that handles explicit downloads. Also
moves the core of DownloadResourceHandler out into a separate class so
that the logic can be shared with the URLRequestDelegate.

Change DownloadUrlParameters::OnStartedCallback to take a
DownloadInterruptReason instead of a net::Error. Also introduce a new
download interrupt reason to indicate that the requested URL was not
allowed.

BUG=7648, 225901
------------------------------------------------------------
Rename DownloadRequestHandleInterface

Now just called DownloadRequestHandle.

BUG=7648
------------------------------------------------------------
Merge creation of DownloadItem and SavePackage item.

BUG=6025
BUG=7648
------------------------------------------------------------
Use DownloadManager from RenderMessageFilter

This may not be completely correct since there should not be any
functional difference between a request intiated via a renderer
ResourceRequest vs. one intiated via an <a download> link. Should
consider reverting this or modifying this to use a modified
ResourceRequest.

BUG=225901
------------------------------------------------------------
Use DownloadManager for PluginInstaller.

PluginInstaller was invoking the BeginDownload method of
ResourceDispatcherHostImpl even though the request wasn't being
initiated from a renderer. Go through the DownloadManager instead since
the PluginInstaller is initiating a programmatic download.

BUG=225901
------------------------------------------------------------
Update origin info after on each response.

When a download is resumed, a new URL request is sent out. The response
received for this request may contain new ETag and Last-Modified
information which should be used for subsequent resumption attempts.
Otherwise if a resource changes (along with the corresponding ETag)
subsequent partial resumption attempts will all fail even if it should
have succeeded.

BUG=7648
------------------------------------------------------------
Don't store or use validators unless they are strong.

ETag and Last-Modified headers shouldn't be used unless they imply
byte-wise equivalence. While RFC 2616 states that a client 'MAY' use them
anyway, we are going to be conservative and only use them if they are
strong.

BUG=7648
------------------------------------------------------------
Cleanup DownloadResourceHandler

* Avoid duplicate assignments.
* Don't calculate whether strong validators are present in an HTTP
  response. A spec compliant implementation of this determination is
  already present elsewhere.

This is in preparation for removing the dependency of downloads on
WebContents.

BUG=7648, 225901