Don't hide 'is_recur' option on Contribution Pages

Allow entering one-off contributions -- and also setting different
periods for recurring contributions, when the contribution page is set
up accordingly. (Hiding the 'is_recur' option made the period fields
unavailable as a side effect -- see issue #91.)

Note that CiviCRM presently does not offer any way to set up
contribution pages that allow *only* recurring contributions -- so now
that the SEPA-specific hack is gone, organisations needing this will
need to find a different way to enforce it...
Factor out mandate creation from doDirectPayment()

In doDirectPayment(), only prepare the parameters for the new mandate,
but don't actually create it here; instead, invoke a new dedicated
function.

This is in preparation for one-off contribution support, where the
mandate creation needs to be invoked from a different place.
Return a success indication from doDirectPayment()

This is not used for recurring payments, but it will be important for
one-off payments.
Handle mandate creation for one-off contribtions
Handle mandate document generation for one-off contribtions

Add the code paths to get the relevant data from `civicrm_contribution`
instead of `civicrm_contribution_recur` when dealing with one-off
contributions.

Also, the payment processor is now fetched through the
mandate->creditor->payment_processor route, instead of
contribution_recur->payment_processor. This works for all contribution
types; so we do not need a conditional here.
Set mandate type (OOFF/RCUR) when creating mandate for new contribution
Reformat some queries for readability

This makes the queries more readable in general; and even more
importantly -- the reason for doing it right now -- makes patches much
more readable.
Handle one-off contributions in query for XML generation

This fixes XML file generation for one-off contributions.

Among the many many possible variations for doing the one-off/recurring
conditional in SQL, the one implemented here offers both good
readability and good performance.

(It actually performs much better than the simplistic condition used
before, because it explicitly matches `entity_table`, and thus allows
using the index we have on the (`entity_table`, `entity_id`) pair...)

Another good option would be using two seperate conditionals for the
`entity_table` check and the `entity_id` check -- preferring one variant
over the other is probably entirely a matter of taste.
Rewrite query to use explicit JOINs

This is a purely syntactic change that shouldn't affect functionality in
any way. However, the closer placing of the join conditions make the
query easier to modify.
Handle one-off contributions in SepaContributionGroup::getdetail query

This fixes listing of one-off contributions on the dashboard. (And
possibly other things?)

For the conditional query, we are using exactly the same approach as in
the XML file generation.
Prevent generating next batch for OOFF contribution groups

Hide the dashboard button for OOFF groups; and also add a sanity check
in the actual API function.
SepaMandate::get() API: Drop "entity_table" default value

Drop the default, and update all callers that relied on it.

I can't see why it would be useful to have such an arbitrary default
here. All it does is breaking things in ways that would be painful to
work around. (For example when doing lookups by `reference` rather than
`entity_table`+`entity_id`.)

This fixes the mandate links on the dashboard for OOFF contributions --
and probably other things too...
Fix CRM_Sepa_Logic_Base::isSDD()

We never ever use the `id` field of `civicrm_option_value`...
Display mandate data in contribution view for OOFF contributions

For OOFF contributions, we don't have a recur record -- so we can't
display the mandate data on the ContributionRecur view, but rather have
to put in on ContributionView.

The code paths used here are pretty much separate from the recur ones,
which does cause some redundancy, but it is for the best: the one-off
case uses a significantly different template, as well as a different
approach for injecting it in the output page -- both of which are major
improvements. (Technically as well as in the user-visible result.) Going
forward, the recur case probably should be aligned with the approach
used here.
Include mandate block in contribution edit form for OOFF contributions

This uses the same (or equivalent) code as the recurring contributions
case -- so it comes with the same assortment of outstanding bugs...
SepaMandate::create() API: Drop `entity_table` and `type` defaults

Rather than setting arbitrary defaults, make the parameters required.

I don't believe such arbitrary defaults are really helpful -- all they
do is hiding potential errors...

No callers seem to rely on the previous behaviour at this point.
Handle non-recur case in page title for SepaMandatePdf
Dashboard: Hide not applicable columns in contributions listings for OOFF groups

I'm actually unsure about this one: while it's nice not to show
meaningless columns, having different table layout between OOFF and RCUR
groups could harm readability when both are expanded at the same time...

A third possible option would be keeping the columns, but making them
invisible.
Set status of newly created contributions to 'Pending'

While the status of newly created recurring contributions is
automatically set to 'Pending', for one-off contributions it's
'Completed' instead. I believe this comes right from CiviCRM Core,
rather than anything related to the SEPA extension -- though I can't
think of a rationale for this inconsistent behaviour...

Anyways, newly created DD contributions should always be considered
pending -- so explicitly set the status accordingly.
Fix str_replace() invocation

Don't fail generating `civicrm_sdd_file.filename` field.

I don't think this is actually used anywhere -- but who knows, it might
some day...