WIP: Fixup: api.SepaTransactionGroup.create spec: pass $params by reference

When not working on a copy, the modifications actually take effect...

- to be folded into orginal updatestatus() commit
DashBoard: Drop JS debugging log statement

This probably has been forgotten, because the output only shows up on
the browser's JavaScript console, which is not visible normally.
However, it's still eating resources...
DashBoard: Make the entire contribution group rows clickable

Instead of limiting the clickable area for activating the detail listing
to a few select fields, make the entire table row clickable.

This is more discoverable, more convenient, and even sligtly simpler in
the implementation. The only minor downside is some possible confusion
about the file links contained within the rows... Still, this should be
acceptable in view of the major benefits.
WIP: Fixup: Avoid PHP notices

- To be folded into original on-demand batching commit
- Not actually tested (except for regressions), as our testing environment doesn't report notices...
WIP: Fixup: Don't overwrite contribution_status when setting sequence_number

Strange behaviour of api.Contribution.create regarding
contribution_status default striking again...

- To be folded into recur handling / sequence_number commit
WIP: Fixup: Drop bogus conditional when setting default `sequence_number`

This never could have worked, because of a mistyped variable name.
(Whoops...)

As it turns out, the conditional was pointless anyways: the API code
setting the custom fields is executed *after* the main entity's post_
hook fires -- so we actually never have an existing value here. Rather,
we can just set a default value unconditionally; and it will be later
overwritten by any value explicitly requested through the API.

- To be folded into original generate recur / sequence_number commit
Move forcing 'Pending' Contribution status form post_ to pre_ hook

Making sure the contribution is created with the correct status right
away is more straightforward and elegant, and indeed more correct
overall.

Notably, having the contribution created as 'Completed', and only later
resetting the status, might have undesirable side effects regarding
Financial Transactions etc.
Drop redundant setting of `payment_instrument_id` in post_ hook

We already set it in the pre_ hook -- which is much more appropriate
anyways.
More obvious check for SEPA in hook_post_contribution_create()

Use the isSDD() method on the Contribution object in question, rather
than relying on global state.

(Actually this is effectively equivalent in the present implementation,
as isSDD is based on the `payment_processor_id` we set from the same
global state in the pre_ hook... However, it still seems more
elegant/obvious/robust to do it this way.)
Refactor: Move mandate creation block inside general SDD conditional

This should not actually affect functionality -- but it's probably
clearer this way.
WIP: updateStatus(): revert to using API for setting contributions 'Completed'

The API automatically creates `civicrm_financial_trxn` records, which is
a good thing I guess... (Even though it fails to use the right Financial
Account specified for the Payment Instrument, using the default account
instead...)

Also dropped $setReceiveDate flag, as it exactly coincided with $useApi
-- so we can just hardcode the behaviour for each case instead.

- to be folded into original updateStatus() commit, I guess
Add new API: api.SepaContribution.get

Trivially provide an alternate Contribution API implementation (under a
different name), using the standard BAO-based approch.

This is necessary, because the official Contribution API has a complex
custom implementation with some serious downsides, making it unsuitable
for our purposes. (Specifically, for efficiently finding all pending
SEPA Contributions.)
WIP: Don't use static 'Pending' groups

Rather than temporarily batching new contributions into static
pseudo-groups, leave them entirely unbatched, and always dynamically
find all pending (unbatched) contributions upon need.

This introduces some new code for finding and displaying the pending
contributions; and it makes the dashboard more complex, because the
pending groups/contributions are not handled uniformly with the batched
ones anymore. However, it also allows us to get rid of some of the
legacy batching code.

The new approach should be easier to follow and more reliable, as it
avoids the need for keeping redundant data (i.e. the static pending
groups) in sync. This fixes some known inconsistencies in this area --
and possibly some yet unknown ones too...

- Ideally, this should be folded into original on-demand batching commit
  -- this was the major unknown in there... Might be tricky though with
  all the other changes that happened in between :-(
- Drop obsoleted code
- Comments for changed batching code
WIP: Exclude pending Contributions from deleted Contacts

Add extra check to not consider Contributions from Contacts with
`is_deleted` status in pending Contributions listing (and batching).

Note: This won't affect Contribution that have already been batched --
they won't disappear from the generated (and probably submitted) SEPA
file, and thus shouldn't disappear from the listing either.
WIP: Don't hide Contributions with inactive Mandates from batched Groups

Once a Contribution gets batched and put into an XML file, it won't
disappear from that file, even if the Mandate is deactivated later on --
so don't hide it from the listing either.

(Note that if a Mandate was already inactive before, the Contribution
won't have been considered for batching into a group/file in the first
place.)
WIP: Batch pending Contributions in a clear order

Sort pending Contributions by type and date during batching, resulting
in the actual batched Groups being created in this defined order as
well.

This is more readable on the dashboard etc.

- To be folded into original "kill pending groups" commit? (With the
  previous batching approach, groups were batched in creation order,
  which is somewhat systematic but not really clear... So not sure
  whether to consider this a regression fix or new functionality.)
WIP: batchForSubmit(): Avoid redundant date adjustment

Instead of doing the (somewhat costly) bank days adjustment for every
Contribution individually, group them by common `receive_date` (and
type) first, and do the calculation only once for each of these groups.

- Is it really worth the effort? (This part becomes *much* faster; but
  it's hardly noticable overall...)
- To be folded into original on-demand batching commit, if "kill pending
  groups" is folded too. (Otherwise, keep it separate, so we get minimal
  changes in the "kill pending groups" commit.)
WIP: Refactor: factor out common Contribution status update code

We had exactly the same code in two different places.

- Move to CRM_Sepa_Logic_Base:: ?
- Move more logic in here? (Completed vs. other)
- Try api.SepaContribution.create; bao->create()
- Fold into original commit? (If both users end up being created in same
  commit...)
WIP: Drop batching hook dispatcher

With the new batching approach, we do not rely on hooks anymore. Make
this explicit by removing the machinery for invoking such hooks.

Note: the equivalent mandate hook machinery is still in use and left in
place for now -- though we might want to replace the automatic magic
with a hard-wired dispatcher at some point, to make it easier to
follow what is actually happening when...
WIP: Generate RCUR: skip deleted contacts

Don't generate recurring contribution installments for recurring
contributions attached to contacts in the trash (i.e. with 'is_deleted'
set).

- To be folded into original generate RCUR commit