Better distinguish didFinishLoad and didStopLoading

Currently, they mean roughly the same thing. didFinishLoad
fires when a navigation successfully completes and no other
navigations are in progress. didStopLoading does the same
thing, but fires whether or not the navigation was successful.

This changes didFinishLoad to mean "a navigation successfully
completed", while didStopLoading still means "there are now
no navigations in progress in this frame". For each
didStartProvisionalLoad, there will be exactly one of:
didFailProvisionalLoad, didFailLoad, didFinishLoad. Prior to
this change, there would be at most one, but it could be that
a load would complete without a matching notification.

This also reverses the order of didFinishLoad and
didStopLoading. didStartLoading and didStopLoading will now
bracket zero to many individual navigation notifications,
which may be interleaved.

This requires 4 changes to consumers of these notifications:
1. http/tests/loading/progress-finished-callback.html
   asserted the old finish/stop ordering, and did nothing
   else. Remove it and its test harness logic.
2. assumed that didFinishLoad would not
   be sent if a new provisional navigation began before the
   finish notification. Change a DCHECK to an early exit.
3. depends on stop firing before
   finish for determining whether all loading is done. Give
   it the ability to determine loading state for itself
   inside DidFinishLoad.
4. chrome/android/ incorrectly listens to the browser process
   equivalents of didStartProvisionaLoad and didFinishLoad to
   determine whether loading is in progress and start/stop
   the progress bar. Switch it to the equivalent of
   didStartLoading and didStopLoading.


Review URL:

Cr-Commit-Position: refs/heads/master@{#357517}
33 files changed