WIP: Fixup: Allow editing mandate without changing IBAN

As the BAO add() method now has mandatory IBAN checks, we need to make
sure we always pass the IBAN when saving any mandate data. Thus, always
pass the account data (IBAN and BIC) from the contribution/mandate edit
form, not only when they have been changed.

(As a side effect, this will automatically normalize any existing IBAN
and BIC when editing a SEPA contribution...)

Possibly we should make the IBAN optional in the add() method again when
editing existing mandates? (Or it might be good to have a distinct
create() method -- not sure what is considered best practice here.) The
above change is probably reasonable regardless: I really can't see a
rationale for explicit checks against passing unchanged account data...
WIP: Work around different form processing in CiviCRM 4.5

CiviCRM 4.5 introduced the new "Chain Select" mechanism, which turns out
not to be robust against form fields being removed.

To get around this, when swapping out the CreditCard payment fields for
the SEPA DD ones during submit processing, instead of actually removing
the original fields, just make them non-mandatory. While this is
somewhat less elegant IMHO, the original fields are not really in the
way when not mandatory...
Check mandatory BIC for non-domestic payments

When checking IBAN/BIC validity, if no BIC was supplied, check whether
IBAN-only is actually allowed for the given IBAN, i.e. whether we are
dealing with a domestic payment.

The check is performed by comparing the country code in the IBAN to the
one in the creditor IBAN. This means we have to retrieve the Creditor
IBAN first, which required some code restructuring.
Perform IBAN/BIC validation on Creditor data too

Add the validation/normalisation calls in the Creditor BAO, as well as
the PP/Creditor edit form.

As the IBAN-only check makes no sense in this case (and there is no IBAN
to check against), this required making the check optional at the code
level.

Note that the validation error is not displayed correctly in the form:
the form bounces, but no error message is shown. I have no idea what
causes this -- I suspect something fishy in the upstream PP edit form...
WIP: Properly handle CORE and COR1 groups

Generate separate Transaction Groups for domestic payments and
non-domestic payments, with the Instrument (<LclInstrm>) set to 'COR1'
or 'CORE', respectively; and with advance times adjusted accordingly.

Also, there is now a new batching option to generate separate files for
'CORE' and 'COR1' groups, while still keeping groups of all Sequence
Types and Collection Dates in one file.

To distinguish 'COR1' and 'CORE' groups, a new `is_cor1` flag is added
to `civicrm_sdd_txgroup`.

- Probably should be merged with original commit introducing the hacky
  hardwired COR1 support
- Still no option to select batching mode without code changes
- Also need an option to disable COR1 generation?
WIP: Add batching option to generate separate files for each Sequence Type

For completeness, add an option to group only different dates but not
different Sequence Types (or Instruments), to complement the existing
options to not group anything; to group everything using the same
instrument; or to group everthing into a single file.

There might or might not be a use case for this -- but at any rate, it
makes the code more regular, and thus probably easier to follow.

- To be folded into original commit introducing batching modes? (And the
  new batching mode introduced with COR1 handling.)
WIP/Hack: Add UI-triggered DB upgrade script for `is_cor1` introduction

To faciliate upgrades to the newer version of the extension with proper
COR1 handling, create a PHP script that performs the necessary upgrade
SQL, and can be triggered by loading 'civicrm/sepa/upgrade' in the
browser.

This is a least-effort approach, until we figure out how the official
approach to extension DB schema upgrades is supposed to work...

- Todo: use proper result page
WIP: Generate more descriptive names for SEPA XML files

If generating separate files for different instruments (COR1/CORE), make
the file names distinct by including the instrument in the name.
Likewise for separate files per sequence type (FRST/RCUR/OOFF), and
separate files per collection date.
Merge branch '4.5-hotfix' into dico-wip
WIP: Adapt Underscore/Lo-Dash inclusion for CiviCRM 4.5 ways

In CiviCRM 4.5, underscore.js was replaced by lodash.js. Also, lodash.js
is now always included in every page served by CiviCRM -- and if we
still try to load it explicitly with addScriptFile(), it leads to a
situation where the system include is automatically omitted to avoid
duplication, which in turn causes failures because the explicitly
requested one is loaded too late for other system scripts...

In other words, if we want to use the CiviCRM-provided copy of Lo-Dash,
we *have* to use the system instance, rather than trying to load it
ourselves. (Plus, it's more efficient anyways.)

Note that this change breaks CiviCRM 4.4 compatibility. I can't think of
a way to make it compatible with both without conditionals or some other
form of non-trivial trickery...
WIP: Dashoard: Wrap js code the "standard" way

The js code was wrapped in a "cj(function($){...})" construct, which is
different from the "(function($){...})(CRM.$)" construct used througout
CiviCRM Core, but appears to behave just the same.

Switch to the "standard" variant for uniformity, and also because it
allows us to import "CRM._" into our scope the same way it's done for
"CRM.$", and like everywhere else in CiviCRM.