[release/6.0] Pass resource items for VS generated authoring

[joeloff]

Description

A non-existing property instead of an item is being passed to the workload generation task. It won't cause build breaks because the task has fallback logic that will extract information from the workload manifest when it generates the SWIX authoring for VS.

It is ignoring all the specific resource values and versions we're providing for workloads. The version numbers are the more critical concern for the component and component group authoring as it will require manually updating authoring in VS when we insert.

Testing

Manually verify the intermediate JSON manifests generated for Visual Studio using an official build. Otherwise, wait for a staging build to verify the files being pushed to VSDROP for an insertion (likely too late to take corrective actions)

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[lewing]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3038953590

[lewing]

/backport to main

[github-actions]

Started backporting to main: https://github.com/dotnet/runtime/actions/runs/3038955202

[carlossanlop]

@lewing @joeloff how confident are that this won't cause a build break like it did in the release/7.0?

[joeloff]

@lewing @joeloff how confident are that this won't cause a build break like it did in the release/7.0?

I'd be very surprised if it did. We already took the Arcade 6.0 update in a previous PR for both runtime and EMSDK- this just fixes a set of values that was incorrectly passed to the build task so it was generating bad descriptions for the items we insert to VS

[carlossanlop]

Apparently the Mono minijit Pri0 Runtime Tests Run Linux arm64 release leg is stuck due to some infra problem:

##[error]We stopped hearing from agent NetCore-Svc-Public 94. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610

Talked to @joeloff and we can merge with the rest of the legs in green.