Update Ginkgo's installation instruction to match Go 1.18+

[thediveo]

At this time, Ginkgo's documentation instructs users to install Ginkgo using

go install -mod=mod github.com/onsi/ginkgo/v2/ginkgo

Now I'm not sure if there are intended side effects of using mod=mod, but if there aren't any, then please update the instructions to follow Go 1.18+ practice:

go install github.com/onsi/ginkgo/v2/ginkgo@latest

[onsi]

the change to add -mod=mod was added by @bdshroyer in this commit

The commit is labeled "Update docs to reflect Go v1.18 installation" and is from this PR: #950

which indicates that this is the issue:

Specifically, the -mod flag is set to readonly by default when the Go version in go.mod is below 1.14 (GInkgo's is 1.12).

Ginkgo's go.mod now lists 1.18 so I suspect we can go back to just go install sans -mod=mod. I'll update the docs but feel free to chime in if you disagree @bdshroyer - you dug into this pretty deeply and I still find that go's various module related flags are opaque to me!

[bdshroyer]

I tried dropping the -mod=mod flag from my installation command in Github Actions and got the same errors that prompted #950. I think the current issue stems from the current backup defaults in the Go Build flags:

By default, if the [go version](https://go.dev/ref/mod#go-mod-file-go) in go.mod is 1.14 or higher and a vendor directory is present, the go command acts as if -mod=vendor were used. Otherwise, the go command acts as if -mod=readonly were used.

I'm not using any vendoring, so go install so unless you set the -mod flag Go currently defaults to readonly mode again and fails because it's barred from fetching the missing dependencies (I checked this by setting -mod=readonly and getting the same error, and then setting -mod=vendor and getting a completely different one that I hadn't seen).

If this is not a widely experienced bug I'll just keep setting -mod=mod for myself, but it looks like the conditions that led me to try it in the first place don't seem to have changed.