`Itertools::format[_with]` docs mention panic within logging macro

[Philippe-Cholet]

Closes #667 and maybe #307.

I merely update the docs of Itertools::format[_with], reformulations are welcome:

⚠ This can happen discreetly and be hard to debug if used in macros of some logging frameworks like tracing! ⚠

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.45%. Comparing base (6814180) to head (df96c73). Report is 107 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #941      +/-   ##
==========================================
+ Coverage   94.38%   94.45%   +0.06%     
==========================================
  Files          48       49       +1     
  Lines        6665     7086     +421     
==========================================
+ Hits         6291     6693     +402     
- Misses        374      393      +19     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Philippe-Cholet]

@Veetaha Does it seem enough to you?

[Philippe-Cholet]

@phimuemue CI of recent #943 was unexpectedly long too (20 minutes more) and I don't know why. This time it's more than 30 minutes.

[phimuemue]

Did we ever think about requiring Clone for format to avoid the panic-problem?

[phimuemue]

@phimuemue CI of recent #943 was unexpectedly long too (20 minutes more) and I don't know why. This time it's more than 30 minutes.

No idea why CI takes so long. I skimmed the individual steps, and they seem to add up to something around 3 minutes. Maybe an infrastructure issue on Github's side?

[Philippe-Cholet]

#307 mentions adding a Clone bound as a possibility but I think that it would be a nasty (not easy to fix) breaking change to do now.

About CI, I don't know what it is. I looked at the log, saw a link about curl 8.0 (in rust 1.71) having time issues but it does not seem relevant to us (being at rust 1.78). Currently, I hope it basically resolves itself, we are not doing anything special. Maybe a github action will have an update that fix this or the GitHub infrastructure will be somehow fixed shortly.