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