gracefully handle elided frames

[drshriveer]

When parsing stacks we frequently encounter elided frames. The actual stack line looks something like ...23 frames elided..., which is passed to parseFuncName, which of course is not parsable as a function name. As a result, whenever this happens we get a useless panic like the following:

panic: Failed to parse stack trace: parse function: no function found: "...23 frames elided..."
goroutine 1 [running]:
go.uber.org/goleak/internal/stack.getStackBuffer(0x1)
	/home/runner/go/pkg/mod/go.uber.org/goleak@v1.3.0/internal/stack/stacks.go:240 +0x65
go.uber.org/goleak/internal/stack.getStacks(0x1)
	/home/runner/go/pkg/mod/go.uber.org/goleak@v1.3.0/internal/stack/stacks.go:84 +0x3b
go.uber.org/goleak/internal/stack.All(...)
	/home/runner/go/pkg/mod/go.uber.org/goleak@v1.3.0/internal/stack/stacks.go:229
go.uber.org/goleak.Find({0xc0003ae880, 0x4, 0x4})
	/home/runner/go/pkg/mod/go.uber.org/goleak@v1.3.0/leaks.go:65 +0x1ea

This PR gracefully handles elided frames to prevent the panic.

[CLAassistant]

All committers have signed the CLA.

[sywhang]

LGTM. Thank you for the contribution!

[prashantv]

In addition to this fixed data test case, can we add or update a test that creates a goroutine with a deep stack that leads to elided frames, and verify that? That way, we'll have coverage that will detect if the elided message has changed.

This is a real concern, when the eliding logic was originally added, it used "stack frames omitted". Given that it has changed, we should have a test that will detect changes by relying on the real runtime logic.

[drshriveer]

@prashantv addressed both comments. If everything looks good, please help merge it in :) - I don't have the necessary permisisons.