Long-running query progress bar improvements

[Matthias]

This issue is to track a few more improvements for the progress reporting of long-running queries added in #895. Based on discussions with @utaal.

• Failing queries can cause multiple progress bars to be added due to search for earlier proof failures and due to recommends checking. At least the multiple proof failure bars should be coalesced and marked (searching for earlier failures) and the bar for recommends checking should be marked (checking recommends). In the short term we can use the span instead to combine some of the progress bars.
• The previous point is fixed for now but @utaal notes that the clean way to do this would be by adding a query identifier, which would also be useful for other things (--expand-errors) as well.
• Personal preference: Set the update rate to 1000 ms so all progress bar timers tick simultaneously, so it's less "hectic".
• Look into how --features record-history interacts with the progress bars. ([Edit by @utaal.] Running on a project that's capturing history currently disables progress bars (because rust_verify perceives stderr as a non-interactive terminal), this is okay, but it may be nice to be able to support progress bars for record-history too. [Edit by @matthias-brun]: https://docs.rs/indicatif/latest/indicatif/struct.InMemoryTerm.html This might be helpful.)
• We may want to add a header to the progress bars Some queries are taking longer than 2s (should be possible as a "static" progress bar with no updating elements)
• We still print the first message with the span after 2 seconds to indicate the out-of-order printing. We could do this more cleanly by either adding a header to the progress bar saying e.g. diagnostics for long-running queries may be reported out of source order or by only reporting the full message with the span once a further diagnostic for the function is actually printed.
• If there are a lot of progress bars we should hide the finished ones until the end.
• More generally, is there a risk that we have so many parallel threads that active progress bars can fill up the whole screen?
• @tjhance points out that using a checkmark is confusing in the case where verification fails.