Update dartc tests and services_test plugins to run from the buildbot_test plugin.

Update dartc tests and services_test plugins to run from the buildbot_test plugin.
Adds the services tests to the buildbot test suite.
Committed: https://code.google.com/p/dart/source/detail?r=19051

[devoncarew, 2013-02-26 04:32:24]

This updates the dartc test suite and the services test suite to run from a
plugin (osgi) context. It also adds the services tests to the ones we run on the
build bots. Services people, let me know if you're ready for them to be running
on each commit or if we should hold off on this.

The dartc tests are not added to the buildbot tests w/ this CL. They take 4 mins
to run. We'll probably want to triage and remove the slower tests.

[scheglov, 2013-02-26 04:50:00]

LGTM

It is sad that we have to make public methods in SelectionAnalyzer just to make
OSGi happy.
Is there any way to avoid this?

Running services tests in good thing!

[jwren, 2013-02-26 07:31:23]

LGTM.  I'm happy to see more tests going in!

On 2013/02/26 04:50:00, scheglov wrote:
> LGTM
> 
> It is sad that we have to make public methods in SelectionAnalyzer just to
make
> OSGi happy.
> Is there any way to avoid this?
> 
> Running services tests in good thing!

[devoncarew, 2013-02-26 14:51:51]

> It is sad that we have to make public methods in SelectionAnalyzer just to
make OSGi happy.
> Is there any way to avoid this?

I'm open to ideas! I did try making the services plugin (and the dartc tests)
fragements. This lets you use the same classloader as the target plugin and
avoid the package access issues. Unfortunately, fragments cannot export any
classes, so the buildbot_test plugin could no longer see the tests from the
services_test plugin. Fragments have other drawbacks as well, and I generally
try and avoid them.

You could specifically exclude the problem tests from the test suites, or from
the buildbot_test suite. This is not a gret long term solution however.

You could try and access the problem method using reflection. This will work in
some cases and not in others.

You could create a subclass of SelectionAnalyzer in the
com.google.dart.engine.services.internal.correction package of the test plugin.
It could see the protected method of the plugin under test, and the unit tests
could test that class instead of the original (parent) one.

Also (and a very simple solution) is to increase their visibility and mark them
as visible for testing! Let me know what you'd prefer.

[devoncarew, 2013-02-26 16:22:20]

Committed patchset #3 manually as r19051 (presubmit successful).