Update to gopkg.in/yaml.v3

[sks]

• Updates YAML dependency to currently supported version (v3), specifically 3.0.1 to avoid a crashing bug:
• https://nvd.nist.gov/vuln/detail/CVE-2022-28948
• v3: panic "attempted to parse unknown event (please report): none" go-yaml/yaml#666

[blgm]

Thanks for this contribution @sks

• Moving to YAML v3 seems sensible as v2 has not been updated in a couple of years, so probably isn't actively supported
• It seems that the vulnerability CVE-2022-28948 does not affect YAML v2: v3: panic "attempted to parse unknown event (please report): none" go-yaml/yaml#666 (comment)
• Because v2 is not affected by the vulnerability, it means that current versions of Gomega are not vulnerable, so we don't need to create an emergency fix today, but we should still aim to create a new release soon.

[thediveo]

The CVE was totally messed up and basically declared everything up to but not including the final v3.0.0 to be vulnerable, while its text stated something else. The GH-CVE has been fixed. Updating to v3 isn't a good idea as the behavior and API has changed, not least in some cases map keys are now string instead of interface{}. Any upgrades needs careful screening and testing. I know as I've been bitten.

[blgm]

Thanks for the warning @thediveo. Now that I think about it, I've fallen over the interface{} -> string key issue before too.

In this case, the YAML parser is used only in the YAML matcher. It's used to decode an Expected and Actual YAML. Because the same parser is used for both the Expected and Actual, I think we should be ok in this case. I understand your argument for not upgrading, and I did consider reverting this PR. But on reflection, we will have to take the leap one day, and all the tests of the YAML matcher are passing. So personally I'm in favour of taking the risk. But I'll defer to @onsi who may want to weigh in.