WithStaticStreamWindowSize should not disable BDP estimation for connection flow control

### Background Transport-level flow control is not tied to application reads, meaning it affects the number of data frames sent without an ACK and directly impacts throughput. Conversely, the stream-level flow control quota [replenishes](https://grpc.io/blog/grpc-go-perf-improvements/#decoupling-application-reads-from-connection-flow-control) only when the application reads the data, making it useful for applying backpressure when the application is slow. ### The Issue In a scenario where an application writes network responses to a slower file system, applying backpressure is necessary. To achieve this, I restricted the stream-level flow control to 1 MB to ensure that at most one 2 MB message is buffered at a time. However, applying a static stream flow control window inadvertently caused the transport flow control window to get stuck at the default 64 KB. Consequently, once the application consumed the initial 2 MB message, the subsequent 2 MB message arrived in 64 KB chunks. Each chunk required an ACK before the next could be sent, severely bottlenecking throughput. ### Workaround To prevent this throughput drop, users must currently manually set the transport flow control window to a value larger than the stream window. ### Fix Setting a static stream flow control window must not interfere with connection flow control settings.