Add intercepters or filters during invocation?

## Describe the proposal
Hello guys, I think We need intercepters or filters(mvc?) during invocation(befor invoke or after invoke) for those reasons:

One:
I have a uniformed api result :
```c#
public class InvocationResult
{
public string Status { get; set; } //"success" or "error"
public int Code { get; set; }
public string? Message { get; set; }
public T Data { get; set; } // <--- there will be the real data of "Product"
}

//Api declared for product
publict Task> GetProductById(int id){
//xxx
}

//for client , i just need the part of the "Data", not all , so the code should be like this(i want):
daprClient.InvokeMethodAsync(request);

//actully i must write code:
var response =daprClient.InvokeMethodAsync(request); // same code everywhere
var product=response.Data;
```
but we can do nothing after get invoke response.

Two:
the endpoint(api) usually protected by "authorize" attribute, so we need to add the authorization header in every request:
```c#
var request = DaprClient.CreateInvokeMethodRequest(httpMethod, appId, methodName, data);

var authorization = HttpContext?.Request.Headers?.Authorization; // same code everywhere
if (!string.IsNullOrEmpty(authorization)) // same code everywhere
{
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", authorization); // same code everywhere
}
return request;
```
as you see, we have to write the same code everywhere( every request per invoke).

if there are some interceptor like mvc. we can solve this elegant。
thanks for your time for read this!

Start by reviewing the DaprClient.InvokeMethodAsync and DaprClient.CreateInvokeMethodRequest entry points mentioned in the issue, along with their existing usage. Clarify the interceptor lifecycle, response unwrapping, and authorization-header behavior before defining the API; done should include an agreed design and coverage for the requested invocation scenarios.

Written by the indexing model from the issue text.