refactor: remove base::Value from WebContentsPreferences

[nornagon]

Description of Change

This refactors WebContentsPreferences to store its values directly, rather than
keyed by string in a base::DictionaryValue. It also centralizes logic for
default values; callers no longer have to provide a default value. And finally,
it centralizes all parsing logic in web_contents_preferences.cc, instead of
having logic for fetching keys by string scattered around the codebase.

I think this is not yet the best form of WebContentsPreferences. In particular,
the Merge method makes me uneasy, but I don't yet fully understand why it is
architected that way currently. It has to do with webviews.

This refactor is motivated by a desire to change the default for sandbox
under complex circumstances. The straightforward approach to that (shown
here)
turns out to not work, because the "defaults" are applied at
WebContents-creation time, so by the time Merge is called, it is not knowable
whether or not sandboxing was disabled by default at creation, or whether it
was unspecified. This refactor allows us to be more explicit about defaulting
logic.

NB, this slightly changes the value of WebContents.getLastWebPreferences(). Previously it included a full copy of the base::Value that backed the WebContentsPreferences. Now it only includes specifically those values that we reference in our own code.

Checklist

• PR description included and stakeholders cc'd
• npm test passes

Release Notes

Notes: none

[nornagon]

ping @zcbenz @miniak , would be great if you could take a look at this!

[zcbenz]

I think this is a this is much better than saving things in a dictionary 👍 .

[nornagon]

CI failures are unrelated; merging.

[release-clerk]

No Release Notes

[nornagon]

Note, this likely breaks @electron/remote, which checks for enableRemoteModule in getLastWebPreferences: https://github.com/electron/remote/blob/c80f8533abb8279c322779ad56ff1336c3eb181f/src/main/server.ts#L291-L292

[miniak]

@nornagon I had vacation last week