support a "go test" format

**Desired feature description**
I use :GoTest from within vim and using the plugin https://github.com/fatih/vim-go; like with other tools (e.g. :make command in vim), they feed from the output having a specific format to populate a list of errors and provide navigation to erroring files:linenumber combinations.

In specific, if I run godog from within go test, it'd be ideal if it'd output lines that matched the expected from the go test command and keep my workflow intact.

Example of failing-test output of a plain `go test -v` run:

```
=== RUN TestSet
TestSet: main_test.go:24: got = 3; want = 9
--- FAIL: TestSet (0.00s)
FAIL
exit status 1
FAIL test_proj 0.038s
```

**Desired solution description**

Having this in my `_test.go` file:

```
...
var opt = godog.Options{Output: colors.Colored(os.Stdout),
Strict: true,
Format: "pretty"}
...
func TestMain(m *testing.M) {
...
for _, arg := range os.Args[1:] {
if arg == "-test.v=true" { // go test transforms -v option
opt.Format = "go-test-v"
break
}
}
...
status = godog.RunWithOptions("test_proj", func(s *godog.Suite) {
FeatureContext(s)
}, opt)
...
}
...
func FeatureContext(s *godog.Suite) {
s.Step(`^there are (\d+) hotdogs$`, set)
s.Step(`^I eat (\d+)$`, subtract)
s.Step(`^there should be (\d+) remaining`, checkRemaining) // this is line:52

s.BeforeScenario(func(interface{}) {
Hotdogs = 0
})
}
```

And when running `go test -v` see the output in the desired format, something like:

```
--- FAIL: TestSuite (0.00s)
main_test.go:52: Expected 7 hotdogs, but there are only 6
FAIL
exit status 1
FAIL test_proj 0.051s
```

**Alternatives considered**

- not running with `godog.RunWithOptions` and instead using a wrapper that'd contain output in the expected format.

An example command for generating output approximating the expected:

```
godog --format=cucumber | jq -r '.[] | .elements[].steps[] | select(.result.status == "failed") | " \(.keyword): \(.match.location): \(.result.error_message)"'
```

This is not an optimal solution as it brings me to the matching method for the step, not to the line in the `_test.go` where the godog.Suite is configured, which I could then use to navigate around in the code.

Start with the _test.go example, especially TestMain and FeatureContext, and run the shown go test -v command to compare current output with the requested format. Trace how godog.RunWithOptions handles the selected format and check that failures point to the _test.go line where the suite step is configured. Done means go-test-v output matches go test conventions and supports file:line navigation.

Written by the indexing model from the issue text.