Improve "fill-instance-hrid" script for avoid failing if invalid data exists.

There is an error while enabling tenant in mod-source-record-storage for different tenants. An error occurred in executing a script named "2020-09-09--15-00-fill-instance-hrid.xml".

There is an error log(see attached detailed logs for more info): 

Caused by: liquibase.exception.DatabaseException: ERROR: more than one row returned by a subquery used as an expression [Failed SQL: (0) UPDATE fs00001019_mod_source_record_storage.records_lb

After investigation, was found multiple occurrences of '001' field in single record. These may or may not be exact duplicate 001s. They may be 001s with different values n them. A valid MARC record can only have one 001 field.

NOTE: This situation is not valid for data-import, so it seems like there was smth manipulation with data inside DB. Best guess is that these records were added directly to the database as part of initial library data migration, bypassing the business logic and UI validation

 Purpose:  improve this script to avoid these errors.

After discussion at Folijet standup, here's the plan:

1. Create a script that checks for multiple 001s in an SRS MARC record and write those out to a file for library review Kateryna Senchenko Will we have a separate Jira for this? We should also make sure that it checks MARC Bibs, Holdings, and Authorities. Please coordinate with Spitfire to ensure it works across all 3 SRS MARC record types
2. Fix the Iris HF3 migration script problem caused by SRS records with multiple 001s (this Jira) and release as a Juniper hotfix
3. Advise any libraries that have not migrated to Iris HF3 yet, or who are stuck with Juniper migration to 1) run the multiple 001 script and then 2) do their upgrade
4. Create a wiki page with ongoing SRS maintenance scripts that libraries may want to run on a periodic or ad hoc basis (for cleaning up HRIDs, identifying multiple 001s, etc) (abreaux and Kateryna Senchenko)
5. Add info to both the Iris and Juniper release notes (abreaux and Kateryna Senchenko)
6. Get a better understanding of when libraries are bypassing the DI and SRS business logic, and see if we can get them to aim for more data cleanup before they push data directly into SRS and/or discourage them from pushing data directly into SRS; Implementers? DI subgroup? Others?