Allow alias.term and alias.type to use project:path syntax

[ceedubs]

The fork command supports a syntax like fork project/branch:path. But alias.term and alias.type don't support the same syntax:

@cloud/nimbus/verify-service-owner-4> alias.type /verify-service-owner-3:JobContext.UserHandle JobContext.UserHandle
 
  1:2:
    |
  1 | /verify-service-owner-3:JobContext.UserHandle
    |  ^
  unexpected 'v'
  expecting '.', end of input, hash (ex: #af3sj3), or operator (valid characters: !$%&*+-/:<=>\^|~)

A workaround is to use names to get the hash and then pass the hash as the first argument.

[hojberg]

Whats the use case for this? Seems weird to me to have an alias pointing at a different branch or project. I guess this is a our way to copy? Hmmm.

[ceedubs]

@hojberg here are a couple of use-cases:

• I want to fork a subnamespace into its own project, but I run into #5044.
• In Unison Cloud we need to be backwards compatible with previous versions of abilities like Log, Remote and Http, so we might need to create an alias for the old version of the type so we can still handle it without depending on the entire old version of the library.
• I introduced some definitions on another branch and I would like to keep them but I've decided to otherwise abandon the branch.

And yeah this is basically a copy; but in Unison you don't really copy a definition; you just add a new name as a pointer to the definition.

[ceedubs]

I ran into this again today. It still feels like it should allow for the same syntax as the fork command.