Switch from unpackaged to packaged

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 `ant updatePackageXml` run against them to update the package.xml file with any new metadata from the branch.