`edit` and other friends that render definitions can emit code with names that don't resolve

Two aliases in a namespace that share a suffix can be referred to by that suffix:

-- in the namespace
one.foo = 17
two.foo = 17

-- in a file, works fine
bar = foo + foo

This is because we can see that the suffix foo is only related to one reference, so it's unambiguous.

However, the same isn't true for aliases defined in a file:

-- in a file
one.foo = 17
two.foo = 17

-- also in the file, doesn't work
bar = foo + foo

This is because we don't have hashes for one.foo and two.foo yet, so we can't say they're the same. Maybe we could do something more clever here, but that's how the current implementation works (and I think it's pretty reasonable).

Now consider this namespace:

-- in the namespace
one.foo#xyz = 17
two.foo#xyz = 17
bar = #xyz + #xyz

If you edit one.foo bar you'll get

-- in the file
one.foo = 17
bar = foo + foo

and that won't parse back, because the suffix foo matches one.foo in the file and two.foo in the namespace, so it's ambiguous.

I think a reasonable fix here is to tweak the pretty-printer to always "suffixify by name" – that is, regardless of the underlying hashes, pick the shortest unambiguous suffix.

That would mean that if you had

one.foo = 17
two.foo = 17

in the namespace, then a reference to that term would be rendered as one.foo or two.foo, not foo as it is now. But that'd fix this bug, which seems better than having our pretty-printer sometimes print slightly longer names than it needs to. No need to change the parser – you could still refer to this term as foo so long as it's not ambiguous (unlike the above example, where there's a file-bound name that ends with foo, making it ambiguous).

unisonweb / unison

`edit` and other friends that render definitions can emit code with names that don't resolve #5344