Migrate Dapr.Client functionality into purpose-specific clients

[WhitWaldo]

Describe the feature

Dapr.Workflows was the first foray into building a client that was separate from Dapr.Client and I think it was a good idea. Where Dapr already takes the philosophy that functionality is opt-in, this further solidifies that approach by ensuring that developers only install those packages that include the features they want to opt into. At a high-level, it means that there's less overhead in terms of unreferenced code, but this also gives us an excellent opportunity to modernize old code.

Add nullability annotations
Most of the Dapr.Client, Dapr.Actor and Dapr.AspNetCore packages appear to have been written prior to .NET 6 which means that they lack nullability annotations. By migrating old code to new packages, it gives us the chance to add these annotations and augment developers' understanding of how methods should work without guessing as to what variables may or may not return null values and why.

Improve documentation
I've learned a lot about why things work they way they do by reading the code base and finding some comments lurking in there explaining important concepts that have no analog to the documentation at docs.dapr.io. As part of copying the older functionality into the newer packages, I think it's important to both look at whether any of these inline comments can be more readily surfaced into the public documentation and if whole sections maybe need a "clarity" rewrite. Ideally, there should be precious little that can only be gleaned from the code base that isn't available in public documentation.

Apply performance improvements
Newer versions of .NET have given us all sorts of async goodies (disposables, enumerables), spans, richer streaming support with serialization and deserialization opportunities, etc. By incrementally shifting functionality over to the new packages, I'd like to take a look at what opportunities we have to lessen the resource footprint of the Dapr .NET SDK while also improving performance and usability.

Broaden testing
The whole of the project spans many unit and integration tests, but I'd like to take this further. I think it'd be great to add the examples in the repository to integration tests so we can validate that they remain current as the SDK evolves and so we can ensure that new functionality is implemented as intended. As part of the migration, we can do a piecemeal evaluation of each possible branch to get better meaningful test coverage than we've had historically.