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.
Fixed problem with PEAR incompatibility.

We want to put the packages directory first in the include list, so we get
the PEAR libraries there instead of the ones installed on the machine.
Updated to match latest version of composer.

I was getting a warning when doing a composer.phar install, about this, so
I ran ./composer.phar update.
Fixed Drupal database settings.

With the change back to using CIVICRM_DSN, the Drupal database settings need
to be changed to work off of that as well.
Need Drupal in order for GenCode.php to work.

GenCode.php pulls a civicrm.config.php template file from the drupal
directory, so we need to pull that in for the tests to run.
Sepated out the Drupal DSN from the Civi DSN.

I want users to be able to specify a separate Drupal DSN when running tests,
so I've changed around the interface to CRM_DB_Settings that lets you pass in
NULL to get CIVICRM_DSN, or you can pass in a settings array or a DSN
formatted the CiviCRM way. That let's us pass in CIVICRM_UF_DSN separately.
Doctrine with new isolated test system.

For the new set of tests I'll be doing with the new doctrine stuff I want
each test to be isolated from each other test. That's tricky with web
applications because the web app frequently uses a separate database
connection from the test system which means you can't wrap each test in a
transaction and then roll it back. Instead you usually do a bunch of table
truncates or deletes to reset back to the default data which is really slow.

To solve this problem, I'm using something called mysql-concentrator which
basically sets up a mysql server proxy that forwards mysql connections to a
mysql server, but it combines them all into one connection which means that
you can start a transaction in one connection which wraps the commands in
another connection and then have the first connection roll everything back.

I've also reorganized the test factory classes a little bit to mimic the same
organizational scheme that the entities ues and made them all inherit from a
base class which makes for less code reuse.

I've also implemented the first test case for
CRM_Event_Form_Registration_Confirm::postProcess. I haven't converted any of
the code to Doctrine yet.