Fix project transfer not prioritizing exact matches

What does this MR do and why?

In !130773 (merged) we fixed the problem where it was impossible to transfer one subgroup to another group when there were many similar matches.

However, a similar problem exists when trying to transfer a project to another group.

The underlying issue appears that the transfer_locations API work slightly differently. The groups transfer_locations API uses ::Groups::AcceptingGroupTransfersFinder, while the projects transfer_locations API uses Groups::UserGroupsFinder.

The latter appears to have logic around permission checking for project creation, transfers, and imports.

To give priority for exact matches, we add an exact_matches_first argument behind the exact_matches_first_project_transfer feature flag.

In theory the sorted_by_similarity_desc could also prioritize exact matches, but to be consistent with ::Groups::AcceptingGroupTransfersFinder we use the same approach.

References

Relates to #536745 (closed)

How to set up and validate locally

1. In some group X (such as sandbox), create subgroup aa.
2. Now create subgroups X/aa/11, X/aa/11/11, and X/aa/11/11/11.
3. Go to a project and attempt to transfer the group inside Settings -> General -> Advanced -> Select a new namespace. Type X/aa in the Search dropdown.
4. Notice the list is sort so that all the subgroups with 11 will be listed first:

5. Now enable :exact_matches_first_project_transfer via bin/rails console: Feature.enable(:exact_matches_first_project_transfer).
6. Reload the transfer page, enter in X/aa in the dropdown. Now the subgroup X/aa should be listed first:

SQL statements

See !130773 (merged). I believe the same query plans apply.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.