Reimplemented CodeGen to work from Doctrine metadata.

We are going to move over to Doctrine and as part of that we want to
have the database defined in only one place. Before Doctrine we were
using a proprietary XML format to store the database schema. Now we
are going to use annotations in the Doctrine entities to define the
schema.

But, we aren't going to cut over to Doctrine all in one go, so we need
to still generate the DAO files which were generated from the XML
format. This changes the code generator to generate the DAOs from the
Doctrine entity metadata instead of the xml files.

Now uses 'bin/gencode' to run GenCode.

Some of the metadata from the XML files isn't coming over in this
version like comments, unique_name, rows, etc... We're not sure what
we're going to do about that yet.
Just pass fields queries to Entity.

Instead of trying to regenerate the fields array, just use the one on
the entity.

Also, fieldKeys can just be rewritten in terms of fields() so it doesn't
need to be explicitly set.
Can't use file_exists to check for classes.

Classes could be in any of the paths. When running the tests, some of
the CRM_* classes are in tests/phpunit/CRM and this prevents them from
loading. If we want to do this, then we need to check all the include
paths, but require_once does that for us, so I'm not sure why we
wouldn't just want to let require_once fail if it can't find the file.
Enity and DAO generation fixes.

I removed the skipTables part of entity generation because it gets into
some kind of infinite loop and I don't think we need to skip it. I fixed
the problem with Case entities, and we can probably deal with the
entity_table problem as well.

Generated entities need to put \ before any CRM_ classes or it can't
find them in the namespace.

Need the $_fields variable to be declared or we get an error.

Changed the listAll template back to use the DAO entity data because
it's easier.
Fixed a problem with DAO classes not existing.

This check was dying because DAO classes might not exist yet they don't
get loaded by the class loader until some code tries to use them. I
think this was working before because the old DAO classes required all
their related foreign key classes, but I took that out to rely on the
autoloader.

I think this is probably better anyway, because we probably want an
exception in most cases where the class doesn't exist and we don't want
to fail silently.
Latest auto-generated entities.

I had to make some changes to the entity generation to get the DAO
generation to work. Here's the entities with those changes.