source.CallExprArgs fails to open target source file when built with -trimpath

Similar to https://github.com/gotestyourself/gotest.tools/issues/274, the CI system I use has multiple concurrent builds and tests running in the same container, so it does source checkouts in temporary paths. This requires the use of `go test -trimpath` to avoid invalidating the cache every time the path changes.

Unfortunately, this also fails with "unable to parse source file" from `source.CallExprArgs`:
```
$ go test -trimpath .
--- FAIL: TestFoo (0.00s)
foo_test.go:10: failed to parse source file foo.module/foo_test.go: open foo.module/foo_test.go: no such file or directory
FAIL
FAIL foo.module 0.106s
FAIL
```

Instead of the expected useful output:
```
$ go test .
--- FAIL: TestFoo (0.00s)
foo_test.go:10: assertion failed: "a" is not "b": some message
FAIL
FAIL foo.module 0.106s
FAIL
```

Here's some simple reproduction code; drop these into an empty directory and run `go mod tidy`. The `foo_test.go`:
```
package foo

import (
"testing"

"gotest.tools/v3/assert"
)

func TestFoo(t *testing.T) {
assert.Check(t, "a"=="b", "some message")
}
```
And `go.mod`:
```
module foo.module

replace foo.module => ./

go 1.19

require gotest.tools/v3 v3.5.1

require github.com/google/go-cmp v0.5.9 // indirect
```

The fix for https://github.com/gotestyourself/gotest.tools/issues/274 at least shows `some message` now, but after even more error messages. Would you be willing to accept a PR with a partial fix for `-trimpath` too?

Go tests are documented to be run from the same directory as the test binary, so it might be possible to infer a relative directory from that. Suggestions welcome for better ideas.