Fix for UnsafelyTreatInsecureOriginAsSecure policy in browser UI

This CL updates secure_origin_whitelist::GetWhitelist() to delegate
parsing the set of whitelisted sites to a new function, ParseWhitelist,
which takes in a string and returns the parsed vector of strings. This
allows callers in the browser process to explicitly parse a whitelist
from either prefs or command-line switches. This allows
SecurityStateTabHelper to have its own custom IsOriginSecureWithWhitelist
function to which it can bind an explicitly passed whitelist of origins,
rather than just using content::IsOriginSecure as the callback to
security_state functions. content::IsOriginSecure uses GetWhitelist()
which only loads the whitelist from command-line flags, which are only
correctly set for renderer processes. The custom callback for
SecurityStateTabHelper allows it to also check prefs for the whitelist,
which is how the enterprise policy is accessible in the browser process
(where security indicator UI logic occurs).

This can cause the pref and the switch to be two different sources of
truth for the origin whitelist, however this simpler fix will be easier
to backport. This fix favors the switch over the pref if both are set,
allowing developers to still set temporary overrides while maintaining
the policy behavior for general users. More general fixes may involve
changing how the whitelist propagates between parts of Chrome
(including in content and blink).

Bug: 869422
Change-Id: I93b46d66844af8cee00d919537ce66fc2c56cd46
Reviewed-on: https://chromium-review.googlesource.com/1157029
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579835}
5 files changed