x/tools/gopls: Hover bug reported by telemetry

[adonovan]

This stack A-IqbA was reported by telemetry:

hover:133 is https://cs.opensource.google/go/x/tools/+/refs/tags/gopls/v0.14.1:gopls/internal/lsp/source/hover.go;l=225 is

return protocol.Range{}, nil, bug.Errorf("type name %q without type spec", obj.Name())

gopls/bug
golang.org/x/tools/gopls/internal/bug.report:35
golang.org/x/tools/gopls/internal/bug.Errorf:2
golang.org/x/tools/gopls/internal/lsp/source.hover:133
golang.org/x/tools/gopls/internal/lsp/source.Hover:4
golang.org/x/tools/gopls/internal/lsp.(*Server).hover:18
golang.org/x/tools/gopls/internal/lsp.(*Server).Hover:1
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch:300
golang.org/x/tools/gopls/internal/lsp/lsprpc.(*StreamServer).ServeStream.ServerHandler.func3:5
golang.org/x/tools/gopls/internal/lsp/lsprpc.(*StreamServer).ServeStream.handshaker.func4:52
golang.org/x/tools/gopls/internal/lsp/protocol.Handlers.MustReplyHandler.func1:2
golang.org/x/tools/gopls/internal/lsp/protocol.Handlers.AsyncHandler.func2.2:3
runtime.goexit:0

golang.org/x/tools/gopls@devel devel linux/amd64 (1)
golang.org/x/tools/gopls@v0.14.1 go1.21.3 darwin/arm64 (1)

Reported using golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

[adonovan]

This stack indicates that obj is a TypeName (Name or alias, but not a TypeParam), but the spec returned by findDeclInfo was not a TypeSpec. I can't explain how this can happen. (At first I assume it was due to obj.Pos() being NoPos, which can happen for "unsafe" package members; they are not caught by the obj.Pkg() == nil check because they do have a package. That is indeed a bug, but it's not this bug.)

[adonovan]

Conceivably another case of AST fixing perturbing positions? (See related #64479.)
In any case, all callers of findDeclInfo should probably handle a nil result instead of assuming that it always succeeds.