ExporterInterface & ExporterBase and refactoring of field wrappers.

A new ExporterInterface and it's default implementation ExporterBase.
The __construct() now takes the mapping as argument instead of the
contact object.

All field wrappers access the contact objects exclusively via the
exporter object. So it's possible to the exchange the contact object
(ExporterInterface::setContact()) and reuse the exporter object for
multiple contacts.

All field wrappers must implement the ExporterMapperInterface.

All CampaignionContactExporter classes have been modified to inherit
from ExporterBase.
[supporter-export] Make the address_mapping part of the Exporter.

This duplicates the definition of the address_mapping. One time for the
fields that the exporter provides another time for the columns that the
CSV contains. Exporters currently don't provide a list of all keys that
they offer. This might be changed at some point. Then it would be
possible to use this list for the CSV-headers.
[newsletters] Remove old migrations so that we don't have to port them.
Introduce Contact plugin system.

The plugin-system consists of the following classes:

ContactManager: Plugin loader and factory. The main class to be used
by code working with contacts. Includes many convenience functions.

ContactInterface: Interface that all Contact classes must implement.

ContactBase: Base implementation of a Contact plugin. Most plugins will
extend this.
Port everything to use the new Contact-API.

This removes the old Contact object. Everything using that needs to be
adapted.

Contact-type features (ie. campaignion_supporter from the
campaignion_starterkit) need to provide a contact class via
hook_campaignion_contact_info().

Profile using any CRM functionality need to provide at least one
contact-type and set the 'campaignion_supporter_contact_type' which
defaults 'contact'. Hint: use "drush vset" or variable_set().

Failing to provide the default contact-type will lead to a
UndefinedContactTypeException being thrown.