Can TDNR do better on constructor matches?

[ceedubs]

Is your feature request related to a problem? Please describe.

I often run into error messages that tell me that a constructor name is ambiguous, but there is enough type information present that I would expect type-directed name resolution to be able to figure out what I mean without further qualification.

Example transcript input

```ucm
fresh/main> builtins.merge

type Type1 = MyConstructor Nat
type Type2 = MyConstructor Text

foo : Type1 -> Nat
foo = cases MyConstructor n -> n

# Example transcript output

fresh/main> builtins.merge

  Done.

type Type1 = MyConstructor Nat
type Type2 = MyConstructor Text

foo : Type1 -> Nat
foo = cases MyConstructor n -> n

  Loading changes detected in scratch.u.

    ❓

    I couldn't resolve any of these symbols:

        5 | foo = cases MyConstructor n -> n

    Symbol          Suggestions

    MyConstructor   Type1.MyConstructor
                    Type2.MyConstructor

🛑

The transcript failed due to an error in the stanza above. The error is:

❓

I couldn't resolve any of these symbols:

    5 | foo = cases MyConstructor n -> n

Symbol          Suggestions

MyConstructor   Type1.MyConstructor
                Type2.MyConstructor

**Describe the solution you'd like**

In this case there are two pieces of information present and I'd expect either one to be enough in isolation to remove ambiguity:

- The input type has been specified as `Type1`, so I must be matching on a constructor of `Type1`.
- The output type has been specified as `Nat`, so I must be matching on a constructor with a single `Nat` value.

The first item in particular seems like a strong signal to TDNR for pattern matches.