Switch to ant updateMetaXml

# Switch to ant updateMetaXml

Previously, we used a Python script for a few different editing operations which are no longer needed with this branch.  The only functionality from the script still relevant to the project was the updating of meta.xml files to the correct version.  This branch moves that functionality into the build.xml file so it can be run by ant instead of Python.

When changing the version of a managed package Cumulus depends on, edit the version.properties file in the root of the repository then run `ant updateMetaXml` from the root of your local repository to update the files.

Fixes #215 

# Switch to using a package and generating package.xml

Fixes #253 and Fixes #251 (at least makes #251 unnecessary).

This branch implements the switch from using unpackaged code deployments to using a package named Cumulus. This approach has the following benefits:

* Moves the process of adding components to the Package into the developer's hands and before the automated build/test. This reduces the risk of human error when building the final managed package release.
* Helps keep the code base lean. This branch deletes 3,812 lines of code from the repository which was mostly metadata definitions unrelated to the package but pulled down from a DE org by the Force IDE. When using packages, the Force IDE only pulls down metadata that is a member of the package avoiding the problem moving forward.
* Makes cleaning all Cumulus code easier as we can retrieve all metadata from a package through the api

The major changes are:

* package.xml now includes <fullName>Cumulus</fullName> which instructs the metadata api to deploy into a package named Cumulus in the org.
* No wildcards are allowed in package.xml
* All subtypes of an object must also be listed in the package.xml
* If the filesystem code defines metadata not listed in package.xml, deployment will fail highlighting the problem.
* Whenever metadata changes, you must run the updatePackageXml target from the root of the repository: ant updatePackageXml. The Force IDE can be configured to automatically run this command to rebuild the package.xml after any file is saved through the IDE.
* When setting up the Force.com nature on a project in Force IDE, you select to retrieve metadata from the package Cumulus rather than selecting individual metadata components
* If you add new metadata through the web UI, you most likely will need to go to Setup -> Create -> Packages and use the Add Components button on the Cumulus package to manually add the components to the package. The exception is if you metadata and then reference it from code already included in the package (i.e. a class).

Switching over to this approach should be mostly seamless. It may generate some merge conflicts in the Cumulus_dev_to_feature branch. Any feature branches the code is pushed into will need to have the `ant updatePackageXml` and `ant updateMetaXml` targets run against them. 

# Include CustomLabel type

The build scripts previously did not handle CustomLabels.  Handling them required some refactoring of the way package.xml is generated as unlike other filesystem metadata types, CustomLabels live in a single file `lables/CustomLabels.labels` which contains multiple xml `labels` elements, one for each label.  The labels must be listed individually in the package.xml file.

# Include API 29.0 Object Elements

Since this branch also updates the package.xml generation to use API version 29.0, the object files now include some extra elements added in 29.0, mostly for Salesforce1 support and configuration.