Package Mode: Use aliases when used in source (#220)

v0.5.0 included #207, which replaced reflect mode with package mode. One
issue with package mode that came up (ref: #216) was that generated
mocks for interfaces that referred to alias types were referring to the
aliases' underlying names instead.

e.g.,
some package:
```go
package somgpkg

import "somepkg/internal/apicodec"
...
type Codec = apicodec.Codec
```

mockgen input:
```go
type Foo interface{
	Bar() somepkg.Codec
}
```
mock:
```go
func (m *MockFoo) Bar() apicodec.Codec { // This is a problem, since apicodec is an internal package.
    // ...
}
```

While technically this problem is solved in Go 1.23 with explicit alias
types representation, (indeed, if you run mockgen on the example in the
linked issue with `GODEBUG=gotypesalias=1`, you get the expected
behavior) since we support the last two versions, we can't bump `go.mod`
to 1.23 yet. This leaves us with the old behavior, where `go/types` does
not track alias types. You can tell if an object is an alias, but not a
type itself, and there is no way to retrieve the object of interest at
the point where we are recursively parsing method types.

This PR works around this issue (temporarily) by using syntax
information to find all references to aliases in the source package.
When we find one, we record it in a mapping of underlying type -> alias
name. Later, while we parse the type tree, we replace any underlying
types in the mapping with their alias names.

The unexpected side effect of this is that _all_ references to the
underlying type in the generated mocks will be replaced with the alias,
even if the source used the underlying name. This is fine because:
* If the alias is in the mapping, it was used at least once, which means
its accessible.
* From a type-checking perspective, aliases and their underlying types
are equivalent.

The nice exception to the side effect is when we explicitly request mock
generation for an alias type, since at that point we are dealing with
the object, not the type.

With this PR, the mocks get generated correctly now:
```go
func (m *MockFoo) Bar() Codec {
    // ...
}
```

Once we can bump `go.mod` to 1.23, we should definitely remove this,
since the new type alias type nodes solve this problem automatically.

Author: JacobOaks

mockgen/internal/tests/alias/interfaces.go

@@ -0,0 +1,47 @@
+package alias
+
+//go:generate mockgen -typed -package=mock -destination=mock/interfaces.go . Fooer,FooerAlias,Barer,BarerAlias,Bazer,QuxerConsumer,QuuxerConsumer
+
+import "go.uber.org/mock/mockgen/internal/tests/alias/subpkg"
+
+// Case 1: A interface that has alias references in this package
+//         should still be generated for its underlying name, i.e., MockFooer,
+//         even though we have the alias replacement logic.
+type Fooer interface {
+	Foo()
+}
+
+// Case 2: Generating a mock for an alias type.
+type FooerAlias = Fooer
+
+// Case 3: Generate mock for an interface that takes in alias parameters
+//         and returns alias results.
+type Barer interface{
+	Bar(FooerAlias) FooerAlias
+}
+
+// Case 4: Combination of cases 2 & 3.
+type BarerAlias = Barer
+
+// Case 5: Generate mock for an interface that actually returns
+//         the underlying type. This will generate mocks that use the alias,
+//         but that should be fine since they should be interchangeable.
+type Bazer interface{
+	Baz(Fooer) Fooer
+}
+
+// Case 6: Generate mock for a type that refers to an alias defined in this package
+//         for a type from another package.
+//         The generated methods should use the alias defined here.
+type QuxerAlias = subpkg.Quxer
+
+type QuxerConsumer interface{
+	Consume(QuxerAlias) QuxerAlias
+}
+
+// Case 7: Generate mock for a type that refers to an alias defined in another package
+//         for an unexported type in that other package.
+//         The generated method should only use the alias, not the unexported underlying name.
+type QuuxerConsumer interface{
+	Consume(subpkg.Quuxer) subpkg.Quuxer
+}