create interface for write data api, implement in CRT

[sbiscigl]

Description of changes:

The change creates a new function for the interface for our HTTPClient called AcquireConnection . The idea here is to create a API that does not rely on polling to read more data. this created issues where we saw hot polling such as in transcribe streaming. The way this API could be invoked is

auto connection = client.AcquireConnection();
auto clientStream = connection.NewClientStream();
clientStream.WriteData(...)
clientStream.WriteData(...)

This create a foundation for non-blocking io where the http client is not waiting for more data, but instead we have have a write API to do this.

Projects like the amazon-transcribe-streaming-sdk used this exact API in the same way to eliminate hot polling.

Added a test in dynamodb to write data over a created connection using the new API. The integration tests exists there because dynamo has http2 apis, and unit testing the CRT is not feasible for this change.

Check all that applies:

• Did a review by yourself.
• Added proper tests to cover this PR. (If tests are not applicable, explain.)
• Checked if this PR is a breaking (APIs have been changed) change.
• Checked if this PR will not introduce cross-platform inconsistent behavior.
• Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

• Linux
• Windows
• Android
• MacOS
• IOS
• Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sbaluja]

Just an idea but is it worth making this (or adding a seperate function) that acquires the connection without blocking i/o? Allows us to potentially lazy-init the connection when we implement the stream that uses these new API's

[sbiscigl]

lets make this one non-blocking, its very easy to make this blocking for our use case, but very hard to make it non blocking in the future. changing

[sbaluja]

super nit: we are transitively including AWS_CORE_API somewhere and that's why AWS_CORE_API works but we should explicitly include #include <aws/core/Core_EXPORTS.h>