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.