Adding rich backwards compatibility support to SDK

[WhitWaldo]

Description

The Dapr runtime commits to remaining backwards compatible on an N-2 release policy. In at least the last several releases, when the runtime has promoted an API from alpha to beta to stable, the .NET SDK has provided day-one support for the updated API signature. These changes were validated using integration tests run against the latest release candidates prior to launch and confirmed to work properly, but it wasn't until the release of 1.17 that we had the testing infrastructure in the SDK to validate against prior versions of the runtime.

As of a recent PR this release, I've updated the build infrastructure to automatically run all unit and integration tests against N-2 and N+1 RCs so I can confirm compliance with the stated SDK compatibility goals.

I confirmed with the runtime maintainers this week during our weekly sync about whether the Jobs stability promotion would be back-patched to the older runtime releases and learned it would not be, that it's the responsibility of the SDKs to engage correctly with any supported runtime versions.

Some of the other SDKs apparently handle this by first attempting the gRPC request against the stable endpoint and, if that fails, try it again against known older method name permutations until it works (or doesn't). I don't think this is ideal so after more consultation with @JoshVanL , I've gone down the gRPC reflection route. Upon connecting and attempting an affected SDK method, the SDK will (via code produced by a new source generator) inquire as to the methods available that fulfill the request and then automatically run through them from later generations to earlier (though if the runtime is responding with a stable generation, it shouldn't take more than the one attempt, unless there's a signature mismatch - and it looks for this in its evaluation).

This PR introduces a source generator not intended for direct use by the public that essentially automatically updates the SDK packages to include backwards compatibility versioning support against the runtime.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #[issue number]

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[codecov]

Codecov Report

❌ Patch coverage is 38.05310% with 70 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.90%. Comparing base (09558e6) to head (8c74494).

Files with missing lines	Patch %	Lines
src/Dapr.Common/DaprRuntimeCapabilities.cs	6.34%	59 Missing ⚠️
...rc/Dapr.Common/DaprFeatureNotAvailableException.cs	0.00%	7 Missing ⚠️
src/Dapr.Jobs/DaprJobsGrpcClient.cs	50.00%	3 Missing ⚠️
...butedLock/Extensions/DaprDistributedLockBuilder.cs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1816      +/-   ##
==========================================
- Coverage   65.30%   64.90%   -0.41%     
==========================================
  Files         298      300       +2     
  Lines        8747     8832      +85     
  Branches     1023     1040      +17     
==========================================
+ Hits         5712     5732      +20     
- Misses       2780     2846      +66     
+ Partials      255      254       -1     

Flag	Coverage Δ
net10.0	64.88% <38.05%> (-0.41%)	⬇️

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.