Remove Reference from StructuredArgument

[sellout]

Overview

Almost everywhere we produce a Reference for numbered args, we also have a
HashQualified Name handy, which is much more consumable by commands.

The only case we don’t have an HQ is in the todo command output, so that now explicitly builds
a HQ.HashOnly.

This also fixes an issue with StructuredArgument handling where alias.term
and alias.type wouldn’t make an alias to a HQ.HashOnly StructuredArgument.

Fixes #4898.

Test coverage

There is a new transcript to replicate the reported issue.

[aryairani]

The following comments aren't specifically about this PR, but:

Almost everywhere we produce a Reference for numbered args, we also have a HashQualified Name handy, which is much more consumable by commands.

Makes me think we should have something isomorphic to (Name, Reference) rather than These Name ShortHash.

The only case we don’t have an HQ is in the todo command output, so that now explicitly builds a HQ.HashOnly.

todo does have a name available that it prints though, it just doesn't load it into numbered-args? or no?

[sellout]

The only case we don’t have an HQ is in the todo command output, so that now explicitly builds a HQ.HashOnly.

todo does have a name available that it prints though, it just doesn't load it into numbered-args? or no?

Yes, so I’m actually a bit confused about when exactly the Reference would get used. The change in question is https://github.com/unisonweb/unison/pull/5019/files#diff-db89d574f836d421e840d72b91dad3f90f89f3a897d448c812ee1d441a3e7630L1442-R1442, and you can see just two lines below setNumberedArgs is respondNumbered $ TodoOutput. And when that TodoOutput is processed, it calls setNumberedArgs using HashQualified Name … so is the linked setNumberedArgs just dead code, or is that there in case something else fails along the way and the later HashQualified args never get set?

[aryairani]

Oh weird. It looks like dead code to me.