Blacklist PDF Browser Plugin on Mac for now

Blacklist PDF Browser Plugin on Mac for now.

Add more comprehensive whitelist/blacklist logic so that we can easily switch defaults.

BUG=24918, 26110
TEST=Install plugin, follow a link to a PDF; you should not get a page with nothing but a crash notification for the plugin.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=30535

[stuartmorgan, 2009-10-28 22:53:52]

We can take another look at this when QuickTime is in better shape and see if
that helps this plugin too, but for now it doesn't look likely to be supportable
for M4.

[Amanda Walker, 2009-10-29 00:00:49]

Rather than blacklist this specific plugin, since we'll want a "real" blacklist
or whitelist for the beta branch, how about having two lists (even if they're
just global string arrays) of black/white listed plugins, with this one as the
initial entry in the blacklist and the previous whitelist as the initial
contents of the whitelist?  That way, when we cut the beta branch, it's just a
matter of deciding "default permit" or "default deny", depending on the results
of testing.

[Amanda Walker, 2009-10-29 00:22:11]

As a bonus, the general solution would also knock off
http://code.google.com/p/chromium/issues/detail?id=26110 :-).

[stuartmorgan, 2009-10-29 23:04:44]

Added full white/list blacklist logic. This does minimal ifdef'ing--which means
a bit of unnecessary runtime work, but that should be negligible compared to the
I/O of loading the plugins--since that seemed clearest, but I can switch to two
larger ifdef'd blocks if you'd prefer.

[Amanda Walker, 2009-10-29 23:40:33]

LGTM.  Maybe add a comment that it assumes the lists will be short (and to
change to a binary search if they get big).