Allow GOVERSION to be overridden

[sudo-bmitch]

The fix in #818 appears to block the ability to specify a GOVERSION other than the go.mod value. In my own scenario, I deploy a library with associated binaries, compile the binaries with the latest version of Go, but leave the go.mod a few releases back to avoid forcing an upgrade on anyone importing the library. Would it be possible to default to GOVERSION if it is defined, or to give a configuration option to allow injecting a version to use?

[spencerschrock]

#850 seems to take an osv-scanner configuration specific approach, which is fine, but is there any value in also supporting the Go native way of doing things via a toolchain directive (if present)?

I assume precedence (from highest to lowest) would go:

1. config override
2. toolchain directive (if present and newer than go directive)
3. go directive

Or rather, it would be:

1. config override
2. the go stdlib version detected in the go.mod, taking toolchain into account

[another-rex]

That sounds reasonable to me, no need to block #850 for this change, but let's keep this issue open until we add a tool chain version extraction as well.