SepaImport: Add dummy function to work around bug in civicrm_api3_generic_getActions()

civicrm_api3_generic_getActions() (in the generic CiviCRM API code) has
a bug where it looks for API functions with the entity name just
lowercased ('sepaimport') instead of using the proper dash-replacement
('sepa_import'). Thus, it doesn't find the
civicrm_api3_sepa_import_create() function, and consequently doesn't
return the 'create' action in the result set.

This commit adds a dummy civicrm_api3_sepaimport_create() function,
which is never actually called, but makes
civicrm_api3_generic_getActions() return the 'create' action.

This allows our import API to work again with newer versions of Eileen's
"csvimport" extension, which actually use getActions() to find Entities
that provide a 'create' action, and thus are suitable for import.
WIP/Hack: Disable customisation hooks for now

We don't use them in any of our installations; and they need adapting to
changes in CiviCRM 4.5. (Causing fatal errors right now.)
WIP/Fixup: Define default value for `sequence_number` field

When using the back-office form to enter new contributions, the value
provided for `sequence_number` in the input field will always overwrite
the default value we set in hook_post_contribution_create(), because the
custom value is stored only after the main entity is stored (and the
main entity's post hook invoked). If we don't have a value set in the
form, a NULL value will be saved.

Giving the `sequence_number` field a default value of '1' makes sure the
right value is stored (unless the user filling the form meddles with
it).

Note: the custom field definition change only takes effect during
installation. For existing deployments, the custom field needs to be
updated accordingly by hand.

- to be folded into commit introducing the `sequence_number` field
Normalise IBAN and BIC before storing in DB

This avoids generation of invalid SEPA XML files when certain types of
unnormalised values are entered, e.g. using lowercase letters. (There
was already some normalisation during the actual file generation -- but
it was incomplete; and this is really the wrong place for doing the
normalisation...) Also the values in the DB are less chaotic this way.

The normalisation is done in the BAO layer, so it will work no matter
how the data is entered. (frontend/backend/import)
Check IBAN and BIC validity at BAO level

In addition to checking the input in the form layer, also do validation
in the Mandate BAO add() method. This shouldn't affect input through the
web forms (both online Contribution Pages and back-office), as that
should already undergo the same checks before passing into the BAO. It
does however introduce account verification for other code paths, such
as the Import API.
Refactor: Move account (IBAN/BIC) cleanup and verify into central function

The Mandate BAO now exports a validate_account() method for cleaning up
and validating the account data -- both before storage in the DB (used
internally), and for input verification in the form layer.