both absolute and relative name for same defn are shown in "needs alias" message

[aryairani]

.foo> 

  I found and typechecked these definitions in /private/tmp/foo/u.u. If you do an `add` or
  `update`, here's how your codebase would change:
  
    x These definitions would fail on `add` or `update`:
    
      Reason
      needs alias   z, .foo.x, x   : ∀ (). () ->{.base2.io.IO} ()
    
      Tip: Use `help filestatus` to learn more.
   
  Now evaluating any watch expressions (lines starting with `>`)... Ctrl+C cancels.

.foo.x and x are the same name, and shouldn't be listed twice. Only z and x should be displayed here. Maybe a "print names" vs "parse names" mixup?

[aryairani]

Related to how ShowDefinitionI calls searchBranchExact with parseNames; partially fishy.

parseNames are what we use to turn names into references (it includes both relative and absolute names), printNames are what we use to turn references into names (sometimes we also use PrettyPrintEnv for turning references into names, so this relates to #978), but cases where we search by name and then try to display the names can't rely on a single Names like they do now.

[aryairani]

Maybe we can consolidate all of these into a clever index structure, and pass in a currentPath to appropriate functions when we need to render or interpret relativized names (maybe it computes a new index structure), with appropriate consideration of suffixified names as well.