Throughput work continued: analyze gRPC message processing and make it more efficient

This is a follow-up issue for the PR #214.
Quoted from the `Future work` section:

> @pragnagopa has been working on analyzing how to boost workers' throughput in the gRPC layer, basically around how workers should handle incoming/outgoing gRPC messages more efficiently.
>
> This PR focused on fixing the bottleneck in the PowerShell specific logic, and the future work should shift focus to the gRPC message processing in the PowerShell worker.
>
> Also, all the measurements and analysis I did for this PR was using the default `PSWorkerInProcConcurrencyUpperBound` value, which is 1, meaning that invocations are not processed concurrently. This default behavior makes sense for the consumption plan, given the limited processing power of the VM used for consumption plan. However, for the premium plan, the VM has much better processing power, and thus the throughput should be analyzed again in that environment with the concurrency support enabled.

- First we need to analyze if the gRPC message processing is a bottleneck. If it is, consider using Rx.NET like the host does, to see if we can get more efficient message processing.
- Throughput analysis should be done again in the environment of a premium plan VM, with concurrency support enabled (`PSWorkerInProcConcurrencyUpperBound` being set more than 1).