This modifies the way orphan removal and processing is done to more
aggressively remove orphans that can no longer be valid due to other
transactions being added or removed from the primary transaction pool.

The net effect of these changes is that orphan pool will typically be
much smaller which greatly improves its effectiveness.  Previously, it
would typically quickly reach the max allowed worst-case usage and
effectively stay there forever.

The following is a summary of the changes:
- Modify the map that tracks which orphans redeem a given transaction to
  instead track by the specific outpoints that are redeemed
- Modify the various orphan removal and processing functions to accept
  the full transaction rather than just its hash
- Introduce a new flag on removeOrphans which specifies whether or not
  to remove the transactions that redeem the orphan being removed as
  well which is necessary since only some paths require it
- Add a new function named removeOrphanDoubleSpends that is invoked
  whenever a transaction is added to the main pool and thus the outputs
  they spent become concrete spends
- Introduce a new flag on maybeAcceptTransaction which specifies whether
  or not duplicate orphans should be rejected since only some paths
  require it
- Modify processOrphans as follows:
  - Make use of the modified map
  - Use newly available flags and logic work more strictly work with tx
    chains
  - Recursively remove any orphans that also redeem any outputs redeemed
    by the accepted transactions
- Several new tests to ensure proper functionality
  - Removing an orphan that doesn't exist is removed both when there is
    another orphan that redeems it and when there is not
  - Removing orphans works properly with orphan chains per the new
    remove redeemers flag
  - Removal of multi-input orphans that double spend an output when a
    concrete redeemer enters the transaction pool

This modifies the way orphan removal and processing is done to more
aggressively remove orphans that can no longer be valid due to other
transactions being added or removed from the primary transaction pool.

The net effect of these changes is that orphan pool will typically be
much smaller which greatly improves its effectiveness.  Previously, it
would typically quickly reach the max allowed worst-case usage and
effectively stay there forever.

The following is a summary of the changes:
- Modify the map that tracks which orphans redeem a given transaction to
  instead track by the specific outpoints that are redeemed
- Modify the various orphan removal and processing functions to accept
  the full transaction rather than just its hash
- Introduce a new flag on removeOrphans which specifies whether or not
  to remove the transactions that redeem the orphan being removed as
  well which is necessary since only some paths require it
- Add a new function named removeOrphanDoubleSpends that is invoked
  whenever a transaction is added to the main pool and thus the outputs
  they spent become concrete spends
- Introduce a new flag on maybeAcceptTransaction which specifies whether
  or not duplicate orphans should be rejected since only some paths
  require it
- Modify processOrphans as follows:
  - Make use of the modified map
  - Use newly available flags and logic work more strictly work with tx
    chains
  - Recursively remove any orphans that also redeem any outputs redeemed
    by the accepted transactions
- Several new tests to ensure proper functionality
  - Removing an orphan that doesn't exist is removed both when there is
    another orphan that redeems it and when there is not
  - Removing orphans works properly with orphan chains per the new
    remove redeemers flag
  - Removal of multi-input orphans that double spend an output when a
    concrete redeemer enters the transaction pool

Ticket purchase, vote and revocation orphan tests have also been added.