Revert of Cache the current WebPreferences on RenderViewHostImpl.

Revert of Cache the current WebPreferences on RenderViewHostImpl. (https://codereview.chromium.org/373323003/)

Reason for revert:
Causes DOA on 38-dev.

https://code.google.com/p/chromium/issues/detail?id=398751

Original issue's description:
> Cache the current WebPreferences on RenderViewHostImpl.
> 
> This makes lookups of a WebPreferences field fast.
> In order do this, add code to listen to all preferences updates in order to recompute the cache.
> 
> BUG=390799
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=284592

TBR=jam, michaelbai, chrishtr, avi
NOTREECHECKS=true
NOTRY=true
BUG=390799
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=286876

[erikchen, 2014-07-31 02:18:58]

Created Revert of Cache the current WebPreferences on RenderViewHostImpl.

[commit-bot: I haz the power, 2014-07-31 02:20:31]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/erikchen@chromium.org/429413003/1

[commit-bot: I haz the power, 2014-07-31 02:20:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-07-31 02:20:32]

No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer or
a provisional committer, _not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[Avi (use Gerrit), 2014-07-31 02:21:57]

lgtm

[erikchen, 2014-07-31 19:51:45]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2014-07-31 19:54:49]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/erikchen@chromium.org/429413003/1

[commit-bot: I haz the power, 2014-07-31 20:00:37]

Change committed as 286876

[chrishtr, 2014-07-31 20:03:15]

Oh this just committed now? That's sad. I fixed the underlying inspector prefs
issue an hour ago. :(

Oh well, I'll just issue a revert of this later.

[erikchen, 2014-08-01 22:36:19]

The revert got pushed to dev channel shortly after the bug was diagnosed. This
revert is for top of tree/canary.

Btw, I looked at your fix for the problem (Delete inspector settings in
WebViewImpl). I agree that deleting the inspector settings will fix this
instance of the problem, but how are you ensuring that similar problems won't
happen in the future? I didn't look too much into it, but it looked like we got
into an infinite loop with observing changes to the pref file & changing the
pref file. Given the severity of the problem, it would be good to see tests that
catch this sort of problem, or a restructuring of the logic to prevent this sort
of problem from occurring.