[submodules] Replace yaml-cpp submodule with vcpkg

[xmkg]

MULTI-2343

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.97%. Comparing base (4980c78) to head (006c521).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4459   +/-   ##
=======================================
  Coverage   88.97%   88.97%           
=======================================
  Files         238      238           
  Lines       15253    15253           
=======================================
  Hits        13572    13572           
  Misses       1681     1681           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jimporter]

LGTM! CI is green, and I've verified locally that there aren't any extra places we need to update our build scripts.

[jimporter]

@xmkg Actually... one question: do you have any thoughts about whether we should pin our yaml-cpp dependency to a particular version? I don't have a strong feeling either way, though pinning would make our builds more reproducible. (We'd probably want to have the Renovate bot suggest PRs for upgrading though, so that we don't forget.)

[xmkg]

@xmkg Actually... one question: do you have any thoughts about whether we should pin our yaml-cpp dependency to a particular version? I don't have a strong feeling either way, though pinning would make our builds more reproducible. (We'd probably want to have the Renovate bot suggest PRs for upgrading though, so that we don't forget.)

Right now, the vcpkg's builtin-baseline acts as a repo-wide pin for all vcpkg deps, meaning that all the deps would be fetched from a particular state of vcpkg registry in time, i.e., builtin-baseline being pinned to commit "x" guarantees that we're always going to get whatever yaml-cpp version is present in "x":

multipass/vcpkg.json

Line 2 in 2eb4538

"builtin-baseline": "4334d8b4c8916018600212ab4dd4bbdc343065d1",

This also applies to the dependency's whole ancestry, too.

That's except for explicit version overrides, see:

multipass/vcpkg.json

Lines 8 to 11 in 2eb4538

	"overrides": [
	{
	"name": "fmt",
	"version": "11.0.2"

I'm okay with explicit pins too, but if our concerns are about reproducibility, "builtin-baseline" should suffice. Let me know what you think.