Upgrade ghodss/yaml, fixes #2763

Short version: #2763 is fixed with this upgrade of ghodss/yaml.

Long version: This is a bug in the new way YAML is being decoded. As described in #2600, the way we handle YAML now is to convert it to JSON then unmarshal using JSON. The problem is that YAML is less specific than JSON so if you have a YAML value of 1234, go-yaml assumes it's an int and encodes it as such, then when it's converted to JSON it's kept as an int, then when it's attempted to be unmarshaled into a string, encoding/json errors.

The only way to fix this without going back to the old way of maintaining duplicate tags, unmarshal methods, inconsistent behavior between go-yaml and encoding/json, etc., is to have ghodss/yaml essentially look at the target JSON struct that you're trying to convert to and figure out if you have a number in the YAML and a string in the struct field, and convert the number to a string in the JSON, and continue with the unmarshaling there. This works and is what is implemented now in ghodss/yaml... but it's a bit precarious because I had to a copy/paste a few hundred lines of code from encoding/json because selecting which struct field to decode into is quite complex. It should be pretty reliable since I am depending only on the JSON struct tag format and encoding/json's interpretation of it, which should be stable, but just wanted to give a heads up as to how decoding works now.