ResponseStream underlying buffer improvements

[SergeyRyabinin]

Issue #, if available:

#58, #1732, #2319

The issue:

• ResponseStream design can attach to an underlying buffer it does not own, a double destruction may occur;
• TransferManager marks a download as complete before the actual destination buffer is flushed.

Description of changes:

• Use std::ios_base::register_callback to get notified if underlying stream is destructed;
• Do not flush in ResponseStream d-tor: it does not make sense, on the next line, proper underlying stream implementation should do it anyway in it's destructor (and should not if flush is not required in their design).
• Flush outcome's bodies in TransferManager before sending a complete notification;
• Update Result's Get<Aws::IOStream object> to be const (for the change above);
  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.

[sdavtaker]

Should we log first and fail assert after during debug?

[SergeyRyabinin]

They are equal in messaging to the developer.
Except FATAL tracing is just a last resort if library is built in Release mode.
It is a really just "not crash", the next line will highly likely produce a memory leak reported by custom allocator set in the API Handle.