three query file ref replacement fixes T50660

1. a typo caused the replacement file ref to come from the old list
   rather than the new/good list. (reference -> newReference; The
   old variable named reference was also changed to oldReference to
   help with future clarity).
2. most places used HashMultimaps, which do not allow duplicates.
   However, some of the replacement logic used ImmutableMultimaps,
   and those do (undesirably) allow duplicates unless the more
   specific ImmutableSetMultimap is used. This could allow the number
   of file reference entries to grow rather large in some edge cases.
3. updating the file ref cache with the new list of entries merged the
   new/good list with the old entries. This is fine for the basic case
   because the replacement ref is taken directly from the new/good
   list. However, if there are two or more bad options, then this logic
   could cause them to continuously alternate between each other, as
   the new/good list only prunes one bad entry at a time, and the merge
   would revive the bad ones as choices for the next call.