LP1819542 Hanging transits can cause checkins to fail

LP1819542 Hanging transits can cause checkins to fail

So two bits of defensive programming for do_checkin:

    sub fix_broken_transit_status
    sub cancel_transit_if_circ_exists

I don't know if the first one does anything useful, but the idea is that it'll
at least temporarily set the copy status to In Transit for any status checks
within the do_checkin method that test for that.  It doesn't actually repair
the status permanently (at least in the case of, say, an existing transit being
re-used for a ROUTE_ITEM event).  We may want to do that.

The second one will abort an associated transit (including retargeting a hold
for a hold transit) if both an active transit and an active circulation exist
for the item.  This handles the situation I've been using to test the bug:

    1) transit an item (CONC90000436 in Concerto)
    2) artificially change its status directly in the database (for example, to
       Available)
    3) check it out to a patron (99999376864 in Concerto), noting
       that the Cancel Transit prompt does not get triggered
    4) check in the item

Signed-off-by: Jason Etheridge <jason@EquinoxInitiative.org>