Replace deprecated 'serde_yaml' with 'serde_yaml_ng'

[vatsalpatel]

serde_yaml has been deprecated and archived by dtolnay. This replaces it with serde_yaml_ng 0.10, which is an API-compatible fork and the most widely adopted successor (~2.8M downloads).

The other major fork, serde_yml, was disqualified due to a soundness advisory and has also since been archived.

All existing APIs used by Figment (from_str, Value, Value::apply_merge(), Error) are identical in serde_yaml_ng, so this is a straightforward rename across 2 files.

All tests pass with --all-features (148 tests including the YamlExtended merge-key doctests).

[polarathene]

Your link to the crate seems to be a 404. Perhaps you meant this repo. The maintainer doesn't appear to be that active on Github with their current profile activity and the repo having no new commits for 7 months.

FWIW: Another alternative that has been getting praise is saphyr which presently has a third-party serde-saphyr crate (reference: saphyr serde support tracking issue).

[vatsalpatel]

Good catch on the 404 — updated the link.

On saphyr/serde-saphyr: I looked into it and I'd prefer to stay on serde_yaml_ng for this PR, for a few reasons:

• serde_yaml_ng is a direct fork of serde_yaml with the same API, so this swap is a true drop-in with zero churn to Figment's public surface. serde_yaml_ng::Error leaks through the impl_format! macro and Value::apply_merge() backs YamlExtended's merge-key support — both are load-bearing.
• Switching to serde-saphyr would be a larger change: it's explicitly flagged as third-party with an open tracking issue upstream, merge-key support would need verification (otherwise YamlExtended regresses), and the public error type would change.
• 7 months of quiet on serde_yaml_ng isn't necessarily a red flag here — the YAML 1.1/1.2 specs are frozen, so a parser that works today is likely to keep working. If the crate does stall long-term, serde-saphyr becoming a first-party option would be a good trigger to revisit.

Happy to open a follow-up issue to track a future saphyr migration once serde-saphyr lands officially.

[lmmx]

I went with serde_norway in the figment2 fork, see:

• refactor: rely on serde_norway crate; deprecate serde_yaml lmmx/figment2#14
• serde saphyr lmmx/figment2#13
• chore: replace serde_yaml with serde_norway lmmx/figment2#8

Note in the PR (14) says:

Better choice than serde saphyr lmmx/figment2#13 which would add new dependencies and so be more disruptive

The serde_norway crate did not introduce any other dependencies but serde-saphyr would have added

dependencies = [
 "ahash",
 "annotate-snippets",
 "base64",
 "encoding_rs_io",
 "nohash-hasher",
 "num-traits",
 "ryu",
 "saphyr-parser",
 "serde",
 "serde_json",
 "smallvec 2.0.0-alpha.12",
]

whereas serde_norway's deps match the serde_yaml crate's deps therefore should be preferred

• see diff lines 413 before and 404 after https://github.com/lmmx/figment2/pull/14/changes#diff-13ee4b2252c9e516a0547f2891aa2105c3ca71c6d7a1e682c69be97998dfc87e
• the one difference is that the unsafe-libyaml dep changes to a unsafe-libyaml-norway dep

dependencies = [
 "indexmap",
 "itoa",
 "ryu",
 "serde",
 "unsafe-libyaml-norway",
]