NOJIRA Fix spelling in move plan dialog
SSP-1848 Find conflicting person records by constraint-violated field

The race condition reported in this ticket was the standard race where
we have multiple threads trying to create a person at the same time.
Usually we address this by falling back to looking up the existing
person after one such thread beats all the others to the commit.

But this particular situation was failing to resolve itself because
the person.username uniqueness constraint was being violated, but the
subsequent lookup was by schoolId and that schoolId didn't match the
schoolId on the person record that caused the violation.

This sort of thing can happen in the real world where the portal
doesn't have access to correct schoolIds, so uses username as both
schoolId and username. So on a first name login thread 1 and thread 2
try to find a person record with username X. Neither find it, so both
try to create that user. Thread 1 does so first, which includes copying
the latest data from external_person onto it such that person.username
and person.school_id match those fields in external_person, not
necessarily whatever was provided by the portal. Then Thread 2 tries
to create another person with username X, which violates the uniqueness
constraint on that column. It would then try to look up that existing
record *by schoolId*. This would yield no results if that field no longer
matched username because it had been "corrected" by the external_person
sync. This would then invalidate the current SpringSecurity context.

The fix was to always look up the existing record using the value of
the column on which the uniqueness violation occurred.