feat(common): retry loops preserve original message

[coryan]

Some applications want to have access to the original message, even after a retry failure.

---

This change is 

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (45f5346) 93.61% compared to head (70a0c86) 93.61%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #12368   +/-   ##
=======================================
  Coverage   93.61%   93.61%           
=======================================
  Files        2029     2029           
  Lines      179812   179847   +35     
=======================================
+ Hits       168333   168371   +38     
+ Misses      11479    11476    -3     

Files Changed	Coverage Δ
...oogle/cloud/internal/async_rest_retry_loop_test.cc	98.62% <100.00%> (+0.01%)	⬆️
google/cloud/internal/async_retry_loop_test.cc	98.86% <100.00%> (+0.01%)	⬆️
google/cloud/internal/rest_retry_loop_test.cc	98.39% <100.00%> (+0.05%)	⬆️
google/cloud/internal/retry_loop_helpers.cc	100.00% <100.00%> (ø)
google/cloud/internal/retry_loop_helpers_test.cc	100.00% <100.00%> (ø)
google/cloud/internal/retry_loop_test.cc	97.72% <100.00%> (+0.08%)	⬆️

... and 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dbolduc]

Ok.

This makes me wonder if we even want to manipulate the status message. We could leave the retry information as error info metadata only.

I am sure there are customers who << status.message() instead of << status, though.