metabib.remap_metarecord_for_bib has bad logic

The first thing done by metabib.remap_metarecord_for_bib is to delete all metarecord_source_map entries where the source is our bib_id.

The second thing done is to loop over metarecord entries by joining to metarecord_source_map with a condition that the source is our bib_id. Which, as we just deleted all of those, will never find anything.

Both of these lines were introduced at the same time in 2010, so I am unsure what the logic is supposed to be. I highly suspect that something that is supposed to be happening is not, though, and that the bad logic is creating problems elsewhere, for example parallel hold targeting that joins to the source map table and can find no entries there. In that case holds are skipped over.