Move where we delete 0confs to avoid blocking the tx processor

Deleting them in <code>MemoryPool#remove_for_block</code> means we're doing so prior to persisting all of the db records for the new block. The effect seems to be that Postgres locks the affected rows and the transaction processor gets blocked when it tries to mark unconfirmed spent outputs for new memory pool transactions until the block processor's db transaction commits -- after all of it's massive inserts. Spotted this phenomenon in the Postgres logs. This work around seems effective. I tested it on bitcoin.toshi.io.