Add YAML deserialization and serialization support

[AdamMagued]

Summary

Fixes #135

Objx provides conversion constructors and serialization methods for JSON (FromJSON, MustFromJSON, FromJSONSlice, MustFromJSONSlice, Map.JSON, Map.MustJSON), Base64, and URL Query strings, but lacked built-in support for YAML documents. Users working with YAML configurations had to manually parse YAML documents outside objx.

This PR adds YAML deserialization and serialization support:

• FromYAML(yamlString string) (Map, error) and MustFromYAML(yamlString string) Map
• FromYAMLSlice(yamlString string) ([]Map, error) and MustFromYAMLSlice(yamlString string) []Map
• Map.YAML() (string, error) and Map.MustYAML() string
• Convenient aliases FromYaml, MustFromYaml, FromYamlSlice, MustFromYamlSlice, Map.Yaml, and Map.MustYaml
• Support for map[string]interface{} and []map[interface{}]interface{} in recursive cleanUp
• Robust error handling recovering from unsupported-type panics during YAML marshaling/unmarshaling

Verification

• Added regression tests in map_test.go verifying FromYAML, MustFromYAML, aliases, error handling, nested YAML mappings, and top-level YAML slices.
• Added tests in conversions_test.go verifying Map.YAML(), MustYAML(), aliases, nested maps with interface keys, and error conditions.
• Ran test suite with race detector: go test -race ./... (100% passed).
• Verified code style and linting: gofmt -d -s *.go and go vet ./... (clean output).

[hanzei]

Thanks for the PR, @AdamMagued! We're going to decline adding YAML support to objx itself. Keeping objx free of dependencies is intentional (we removed testify in #159 for the same reason). Adding gopkg.in/yaml.v3 would make every objx user pull it in, including testify, and yaml.v3 is no longer maintained.

You can already do this without new APIs:

var m map[string]interface{}
err := yaml.Unmarshal(data, &m)
o := objx.New(m)

The one real gap is nested maps with non-string keys (map[interface{}]interface{}), which objx.New can't traverse. A dependency-free fix for that would be welcome. For example, the cleanUp changes from this PR on their own, with tests, so they work no matter which decoder produced the data.