Regression test for a crash in the method-set index when a type has
both an ordinary method and a generic method (Go 1.27).

Generic methods are skipped while building the method-set index (they
do not participate in interface satisfaction), but the surrounding type
is still indexed because its ordinary method gives it a non-zero mask.
A bug once pre-sized the method slice to the full method-set length and
filled it by index, so skipping the generic method left a nil hole;
iterating those methods during a search panicked with a nil-pointer
dereference.

The query and its implementer are deliberately in different packages so
that the search goes through the serialized methodsets index (the path
that held the nil hole), not the go/types-based local path.

See the fix in gopls/internal/cache/methodsets, follow-up to golang/go#77549.

-- flags --
-min_go=go1.27

-- go.mod --
module example.com
go 1.27

-- a/a.go --
package a

// C has an ordinary method G, so it is recorded in the method-set
// index, and a generic method F, which is skipped during indexing and
// must not leave a nil hole. C implements b.I via G alone.
type C struct{} //@loc(C, "C"), implementation("C", I)

func (C) G(int) {}

func (C) F[T any](T) {}

-- b/b.go --
package b

type I interface { //@loc(I, "I"), implementation("I", C)
	G(int)
}
