fix: set MAX_CONCURRENT_STREAMS to usize::MAX if no value is advertised initially

[magurotuna]

Currently, if the server provides no value as MAX_CONCURRENT_STREAMS in its initial SETTINGS frame, the client keeps using the value set by h2::client::Builder::initial_max_send_streams. However, given that the absence of MAX_CONCURRENT_STREAMS in the initial SETTINGS frame implies that the server is willing to accept unlimited number of concurrent streams, it is more reasonable to overwrite the value set by h2::client::Builder::initial_max_send_streams with usize::MAX in this case.

Note that this overwrite only happens when the server does not advertise MAX_CONCURRENT_STREAMS in its initial SETTINGS frame. For second and later SETTINGS frames that do not include MAX_CONCURRENT_STREAMS, the client will not update the value and keep using the previously advertised value.

This PR extracts some part from #732.
Related to #731.

---

Consideration

What value is set in this particular case varies among HTTP/2 implementations. For instance, Go uses 1,000 and nghttp2 uses infinity. I chose infinity tentatively, though it should work fine.

[seanmonstar]

Thanks for separating this out, it's a great improvement and I appreciate that it's more compact :)