Failing tests for splitting a Report.

The same failures occur on Blocks, but they share the code.
Previously, RTIR would hardcode the lowest Incident ID into the Split
page and then use that one.  With the change to letting you choose which
Incident you want applied (both, all 3, one, a different one?) it
uncovered a bug that RTIR had even more hardcoding of which
incident to link to.

This code tests that you can apply the split Report to both incidents,
can choose the second incident and can choose a third different
incident.
Stop choosing an Incident for the User.

In 2.4/2.6 this UI hid the choice of Incidents from the end user.  You
could have a Report linked to two Incidents and RTIR would display and
then use only the first Incident.

Now it at least obeys input from the end user as to which Incident to
link to after the Report is linked.
Display default Incidents as selected

The core ColumnMap entries used by RadioButton or Checkbox types (such
as the ones used in SelectIncident) grovel in DECODED_ARGS to figure out
what to select.  I'm not thrilled with jamming things into DECODED_ARGS
but there are a few parts of core that do it, and there isn't another
API to set selected status in ColumnMap from a distance.

Without this change, when Splitting a Report or Block, SelectIncident
will show the Incident(s) parent(s) without selecting anything, so
you're likely to forget to go check the boxes.
Merge branch '2.9/split-multiple-incidents' into 2.9-trunk