Make Dapr.Workflow a single NuGet meta-package

[Copilot]

• Restore single-Dapr.Workflow meta-package bundling all Dapr.Workflow.* siblings.
• Revert Dapr.Workflow.csproj <Description> to "Dapr Workflow SDK for building workflows as code with Dapr".

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.47%. Comparing base (7ecbb8d) to head (ccf4163).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1824      +/-   ##
==========================================
+ Coverage   63.46%   63.47%   +0.01%     
==========================================
  Files         312      312              
  Lines        9279     9279              
  Branches     1101     1101              
==========================================
+ Hits         5889     5890       +1     
- Misses       3129     3130       +1     
+ Partials      261      259       -2     

Flag	Coverage Δ
net10.0	63.46% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[WhitWaldo]

@copilot If I just run dotnet pack Dapr.Workflow from /src, I see this pack only Dapr.Workflow as expected. But if I run dotnet pack from the solution root, I see that it builds the other packages. I need to ensure that when this runs the build in GitHub actions, it's not going to build and deploy all these extra NuGet packages (again, the goal is to bundle everything as the one Dapr.Workflow NuGet package). Can you please address this?

[Copilot]

@copilot If I just run dotnet pack Dapr.Workflow from /src, I see this pack only Dapr.Workflow as expected. But if I run dotnet pack from the solution root, I see that it builds the other packag...

I just verified this on the current HEAD (ccf4163) by running a clean dotnet pack --configuration release from the solution root. The only Workflow-family nupkg produced is Dapr.Workflow.1.18.0-rc02.5.nupkg — no Dapr.Workflow.Abstractions, Dapr.Workflow.Grpc, Dapr.Workflow.Analyzers, or Dapr.Workflow.Versioning* nupkgs are emitted. The <IsPackable>false</IsPackable> set on each sibling csproj (in 029fc10) suppresses nupkg generation even though the siblings still get compiled as project references. So the CI dotnet pack step in sdk_build.yml will only upload/publish the single Dapr.Workflow package — no extra Workflow.* packages will be deployed. If you were seeing sibling packages locally, it was likely from a build prior to that commit or from stale artifacts under bin/Release/nugets/; an rm -rf bin/ and re-pack should give a clean single-package result.