**Context**
`TermSqlIndex` is still the only implementation of `LabelConflictFinder` that is used to find conflicts in labels and descriptions when creating properties and items, that is used in few places such as `LabelUniquenessValidator`.
**Problem**
We will not be able to stop writing to both term stores before we provide an implementation that looks up possible conflicts in the new store.
**Solution**
Provide a new means (interfaces + implementations) that allows writing uniqueness validators using the new store
Check if there are indexes on new tables to support this.
**Todo**
[] add implementation for detecting label and label+descripton collisions [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/546898 | patch for review ]]
[] allow validating on ChangeOpResult for optimized validation on only changing parts [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/550703 | patch for review ]]
[] add ChangeOpFingerprint and ChangeOpFingerprintResult to allow identifying and attaching validators to only fingerprint changes [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/550730 | patch for review ]]
[] use ChangeOpFingerprint everywhere to wrap change ops to terms [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/552905/ | patch for review ]]
[] add validator implementations [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/553213 | patch for review ]]
[] wire up the new validators when reading from new store (migration values of `MIGRATE_WRITE_NEW` or `MIGRATION_NEW`) into ChangeOpFingerprintResult
[] call `ChangeOpResult::validate` in `EditEntity` right after obtaining it