Easy to run tests.

Made a new script (./tests/run.php) that when run out the civicrm-core
repository can setup most eveything needed to run tests and then run the
tests. For the unit tests, it should just run with no dependencies, but for
the Web (Selenium) tests, there are the following requirements:
drush
firefox
apache (or some other HTTP server)

With all that available, it will download and setup Drupal and suggest Apache
settings.

This was developed on Ubuntu, but I would like to get it working on other
platforms.

Run it with -h to see the options.
Grab packages repository if missing.

For true one command tests, we'll need to grab the packages repository if it
is missing.
Better error message when DB connection error.

If you aren't using the MySQL RAM disk server, then you'll need to edit
the tests/phpunit/CiviTest/civicrm.settings.local.php file. This makes
that more clear.
Switch test runner to use Console_Getopt.

Lobo wanted to avoid adding the optionparser package to the packages
directory because Console_Getopt duplicates some of that functionality.
I made a new class called CRM_Utils_CommandLineParser which adds some of
the extra functionality I wanted from optionparser on top of
Console_Getopt.
New basis for Doctrine for CiviCRM.

This is a little different than my first attempt. I'm using annotations
instead of YAML now, mostly because I'm agree with Tim in that it would be
nice to have the database information near the definition in the entity. The
only thing I'm worried about is if we start putting other files in this new
hiearchy in src, that it will slow down the annotation parser because it will
have to read in a bunch of non entity files. I think YAML would be better in
that case because we'd store the metadata outside the class file hieararchy.

I've also split out the entities into roughly the same hiearchy as the
existing CRM DAO objects. Seems more organized that way.

I also fixed the problems the earlier version had with loading the DB
settings when running in the production environment. Now the entity manager
looks for the CIVICRM_DSN constant and initializes everything using that.
Use the cache for the annotations.

Parsing the annotations can be slow, so we want to cache the parsed
annotations, but I was still passing in the AnnotationReader instead of the
FileCacheReader to the AnnotationDriver so it wasn't actually using the
cache.
Filling out Doctrine Event implementation.

Implemented setting up price sets for an event entity.

Implemented setting payment processors for event entities. This was prety
tricky as payment processors are stored as a ids separated by
CRM_Core_DAO::VALUE_SEPARATOR in a VARCHAR column. And Doctrine doesn't
support that kind of one-to-many relationship. I was able to get the behavior
I wanted with a combination of lifecycle events that make sure that any added
PaymentProcessor entities get persisted first and when they get added to an
event, the event registers a postPersist listener that then updates the
event's payment_processor value after the PaymentProcessors have gotten ids.
Fixed event->payment_processor saving.

If you added a payment processor that already exists in the DB to an event,
it wasn't updating the payment_processor field correctly.
Partial revert back to using CIVICRM_DSN for tests.

I wanted to move over from a string DSN definition for the database stuff to
an array configuration, but that proved to be to radical a change on the
non-test side, so I'm changing things back for the easy test stuff to use
the CIVICRM_DSN so it plays nicely with everything including Jenkins.