checkescape conflates source files with the same name in different packages

### Description

checkescape (`//tools/checkescape`) uses `go tool objdump` to produce a mapping from source lines to function calls at those lines (`checkescape.go:loadObjdump()`). However, `go tool objdump` only prints the basename for each source line, e.g.:

```
TEXT gvisor.dev/gvisor/pkg/sentry/mm.(*MemoryManager).MRemap(SB) pkg/sentry/mm/syscalls.go
syscalls.go:348 0x8737e0 4c8da42458fcffff LEAQ 0xfffffc58(SP), R12
...
```

This was discovered in the context of #9072, where checkescape confuses `kernel/syscalls.go:494` (`kernel.IncrementUnimplementedSyscallCounter()`) for `mm/syscalls.go:494` (after this change, the call to `MM.findAvailableLocked()` in `MM.MRemap()`) and emits a false positive:

```
arm64...checkescape: pkg/sentry/kernel/syscalls.go:494:6: stack: possible split on function entry → gvisor.dev/gvisor/pkg/sentry/mm.(*MemoryManager).findAvailableLocked (GOOARCH=arm64, GOOS=linux)
amd64...checkescape: pkg/sentry/kernel/syscalls.go:494:6: stack: possible split on function entry → gvisor.dev/gvisor/pkg/sentry/mm.(*MemoryManager).findAvailableLocked (GOOARCH=amd64, GOOS=linux)
```

AFAIU the cleanest fix would be to plumb a flag through `go tool objdump` (Go: `cmd/objdump`) to `cmd/internal/objfile` that causes `objfile.Disasm.Print()` to print full filenames.

### Steps to reproduce

_No response_

### runsc version

_No response_

### docker version (if using docker)

_No response_

### uname

_No response_

### kubectl (if using Kubernetes)

_No response_

### repo state (if built from source)

_No response_

### runsc debug logs (if available)

_No response_