mac: Remove explicit dependency from many test targets on webcore

mac: Remove explicit dependency from many test targets on webcore

This was added back when we were using a 32bit linker, as a manual hint
to ld. Now that webcore is split up and we use a 64bit linker, it's no longer
necessary.

It also breaks the component build, which relies on everything just depending
on libwebkit.dylib.

BUG=43791, 90078
TEST=things still build
TBR=mark

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

[commit-bot: I haz the power, 2012-03-15 04:35:41]

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

[commit-bot: I haz the power, 2012-03-15 05:51:39]

Try job failure for 9700055-1 (retry) on win for step "compile" (clobber build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...

[commit-bot: I haz the power, 2012-03-15 13:40:30]

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

[commit-bot: I haz the power, 2012-03-15 13:40:31]

Can't apply patch for file chrome/chrome_tests.gypi.
While running patch -p1 --forward --force;
patching file chrome/chrome_tests.gypi
Hunk #1 succeeded at 862 (offset -35 lines).
Hunk #2 succeeded at 2308 (offset -28 lines).
Hunk #3 succeeded at 3120 (offset -22 lines).
Hunk #4 succeeded at 3347 (offset -22 lines).
Hunk #5 succeeded at 3431 (offset -22 lines).
Hunk #6 succeeded at 3554 (offset -22 lines).
Hunk #7 succeeded at 3878 (offset 5 lines).
Hunk #8 FAILED at 3997.
Hunk #9 succeeded at 4024 (offset -124 lines).
Hunk #10 succeeded at 4334 (offset -129 lines).
1 out of 10 hunks FAILED -- saving rejects to file chrome/chrome_tests.gypi.rej

[commit-bot: I haz the power, 2012-03-15 13:47:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/thakis@chromium.org/9700055/6003

[commit-bot: I haz the power, 2012-03-15 15:22:56]

Change committed as 126913

[Robert Sesek, 2012-03-15 15:32:24]

Why was this TBRed?

[Nico, 2012-03-15 15:41:36]

On 2012/03/15 15:32:24, rsesek wrote:
> Why was this TBRed?

Is there a problem with it?

The CLs that added this all sounded like nobody was happy that this was added in
the first place and it looks like it's no longer necessary. (In a way, it's
"Revert a workaround that's no longer necessary" – most reverts are TBR'd)

[Mark Mentovai, 2012-03-15 16:46:52]

LGTM, but this wasn’t so crucial that it needed to be committed as TBR. Lay off
the TBR switch a little bit.