Simplify how TestChromeWebUIControllerFactory is registered now that multiple WebUIControllerFactor…

Simplify how TestChromeWebUIControllerFactory is registered now that multiple WebUIControllerFactory instances are supported. Instead of compiling the test code into the shipping product, have tests which use it unregister the default one and register the test one. This also makes the non-test version used for the majority of the test, which keeps the browser_tests more like the shipping product.

I've also moved the test harness code to chrome\test\base, which is where test harnesses live.

BUG=169170
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=179271

[scr, 2013-01-29 01:01:53]

https://codereview.chromium.org/12084029/diff/2007/chrome/test/base/web_ui_br...
File chrome/test/base/web_ui_browsertest.cc (right):

https://codereview.chromium.org/12084029/diff/2007/chrome/test/base/web_ui_br...
chrome/test/base/web_ui_browsertest.cc:326:
ChromeWebUIControllerFactory::GetInstance());
See comment below - would it be easier to use if this were more like a stack and
we didn't have to unregister the previous one, just register/unregister ours?

https://codereview.chromium.org/12084029/diff/2007/chrome/test/base/web_ui_br...
chrome/test/base/web_ui_browsertest.cc:356: test_factory_.get());
Should the old one be put back?  If so, would some sort of stack registry be
easier - you could just register & unregister yours without caring/knowing what
was there before…

[scr, 2013-01-29 01:30:10]

https://codereview.chromium.org/12084029/diff/2007/chrome/test/base/web_ui_br...
File chrome/test/base/web_ui_browsertest.cc (right):

https://codereview.chromium.org/12084029/diff/2007/chrome/test/base/web_ui_br...
chrome/test/base/web_ui_browsertest.cc:326:
ChromeWebUIControllerFactory::GetInstance());
Per IM, the goal is to get to multiple non-overlapping factories registered, so
the answer is no - it shouldn't be a stack.  That said, it would be nice if the
main factory were implemented with some means to populate a hash rather than
walking each of its known types and individual factories could register what
they knew.

If we had that, then you could see each host -> WebUIMaker be more like a stack,
where you could override temporarily.

FWIW, I added this only in this factory originally because I didn't want to add
any complexity to the non-test runtime, but seeing how the runtime does that big
if if if block in its GetWebUIFactoryFunction, I think the eventual overhaul to
support this natively (ditching this specialty class altogether) would save
cycles in the long run and be easier to understand.

https://codereview.chromium.org/12084029/diff/2007/chrome/test/base/web_ui_br...
chrome/test/base/web_ui_browsertest.cc:356: test_factory_.get());
Neg - read above.

[scr, 2013-01-29 01:30:17]

lgtm