meta: request output of go list -m all in the issue template

[bcmills]

As @FiloSottile notes in #30241 (comment):

I actually don't want to have to figure out if a crypto/tls internal failure is due to a replaced chacha20poly1305.

But of course the same is true for x-repo interdependencies in general: if someone is reporting an issue against, say, x/tools or x/net, it would be really helpful to know the exact version in which they found the issue, and whether any of the dependencies involved have been locally modified.

I propose that we request go list -m all alongside go env in the issue template.

(CC @thepudds @myitcv @bradfitz)

[thepudds]

This is probably good to do independent of the outcome of #30241.

Some people will want to remove proprietary or internal modules from the output of go list -m all, or substitute in foo or corp.example or similar. The template could attempt to briefly mention that is fine to do. Alternatively, could instead just wait to see if it confuses anyone in practice.

If you are not running with module mode enabled, go list -m all currently reports:

go list -m: not using modules

That is probably fine and understandable enough to not confuse people.

[rsc]

Removing from proposal process. Release team can decide on their own here; it's easy enough to change if we get it wrong.

[dmitshur]

This seems reasonable, @bcmills want to send a CL for this? We can try it and adjust based on experience.