WIP: PP: doDirectPayment(): Get Creditor from passed `payment_processor_id`

There is no need to rely on passing the Creditor through a global
context from the validateForm hook, as the Payment Processor used is
always available as an explicit parameter in doDirectPayment(), which is
what we get the Creditor from anyways.

Unfortunately, we still need to pass the `payment_instrument_id` in the
context, as there is no other way to know that we are dealing with a
SEPA contribution in the Contribution create pre hook.
sepa_civicrm_validateForm(): Don't store `payment_processor_id` in global context

It was neither used nor necessary -- the PP is passed directly in many
contexts, while in others having the `payment_instrument_id` is
sufficient.
validateForm(): Check IBAN/BIC validity in back-office forms too

Thus far the sanity checks were applied only on the Online Contribution
Pages, but not for any values entered through the back-office forms.
templates: SepaMandate: Split out generic part

The template adding mandate data to the back-office forms for editing
contributions (OOFF Contribution records and Contribution Recur records)
used to contain the actual Form fields wrapped in a CRM accordion.

For creating new back-office PP-based contributions, we will need the
same form fields, but included differently, without the wrapper. Thus,
split the actual fields out into a reusable common file.
WIP: Allow entering new SDD Contributions through back-office interface

The existing "Add Credit Card Contribution" back-office form is
essentially the canonical method for adding new PP-based Contributions.
It only supports Credit Card Providers out of the box, because that is
what the PP mechanism itself was primarily built for; but it turns out
it can be made to work with our SEPA Processor too, using some form hook
hackery (not more than for the Online Contribution Pages) -- thus
providing a streamlined UI handling SDD just like other types of
automated payments, with fairly little new code.

We expect that this approach will enable SDD-based Membership Paymennts
as well without too much extra work.

Note: the form currently filters out any PPs not declared as Credit Card
Providers. To make it admit the SEPA PP as well, we needed to change the
`payment_type` of the SEPA Payment Provider to "Credit Card". While this
is a misnomer and probably quite confusing, it doesn't appear to cause
any actual ill effects...
Allow setting execution date for one-off Contributions

While the back-office form for entering new PP-based contributions has a
Start Date field for Recurring Contributions, it doesn't have an
equivalent field for setting an explicit Receive Date for single
Contributions. However, the Start Date field is actually also available
when not selecting the recurring option; and it seems an obvious choice
to use it as the execution date for single Contributions as well.

The value indeed already is being passed by CiviCRM as `receive_date` to
the PP callback -- but not to the Contribution creation. Propagating it
explicitly from the PP appears to be sufficient to make this work fully.

This is a PP-specific workaround of course. Most likely the incomplete
support should be considered a bug ideally to be fixed in CiviCRM
itself...
WIP/Hack: Hard-disable mandate mails for now

The risk of accidentally sending a totally inappropriate mail is too
high -- especially now with the backend interface, where the checkbox
could be accidentally toggled every time a new contribution is entered.

We need to revisit this when we have a sane dafault template; when we
have decided how to handle mandate translations; how to handle
unconfigured templates; and in which situations we really want automatic
sending in the first place...
WIP/Hack: Optionally create separate files for each group

Some banking systems fail to process SEPA XML files with more than one
group. (Although these are perfecty valid... Hurray for "standards".)

To deal with such broken systems, it is now possible to choose whether
to put all upcoming groups in one XML file, or generate a separate file
for each.

The actual setting is hardcoded for now. (For DiCo, we keep the much
more convenient variant with all groups in one file...)
WIP: setContributionStatus(): Don't choke on `receipt_date` or `thankyou_date`

Just like the `receive_date`, they need to be reformated for the
BAO->save() method to accept them. (Unless they are not set at all.)

- To be folded into commit(s) originally introducing the BAO-based update
WIP: Disable PHP timeouts for long-running actions

Generating upcoming recurring payments, as well as batching / batch
status change actions, can take quite a long time -- especially on slow
shared servers. Thus we try to disable the PHP timeout before starting
these actions, so they get a better chance of completing...
WIP: Move timeout disabling into the affected functions

Rather than setting it at the UI entry points, do it in the actual
long-running functions.

This should be more generic. It will apply to createnext() executed as a
scheduled job too, for example.

Not sure whether there are cases where it might actually not be
desirable...

- To be folded into previous commit?
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.
Merge branch 'dico-wip' into bos
Local/Hack: Half-automatic upgrade script for PP upgrade

Add a PHP script invocable through civicrm/sepa/upgrade that uses API to
change the `payment_type` field in `civicrm_payment_processor_type` and
`civicrm_payment_processor` from 9000 to 1, as needed by the new
backoffice SDD contribution create.
Local: New private version: bos-production-2