Catch unwinds from the global ctxt callback to complete queries profiling data in more cases

[lqd]

The driver/compiler interface provides multiple callbacks, and we sometimes catch unwinds to flush diagnostics, ensure ICEs appear, and so on even when fatal errors occur.

When these panics happen, we don't finish the TyCtxt, and there's a fixme about that. Unfortunately this is where we also allocate the self-profile strings: query events for example start as virtual and are turned into real strings by this finalization process; they are invalid without this step. When fatal errors happen, the in-flight query name will be <unknown>, event counts will be inaccurate, etc.

This PR catches panics from another of these callbacks, where the TyCtxt is available, to allow for the self-profiling data to be computed before continuing the unwinding process as before. finish does more things, that I don't want to introduce here.

I remember seeing this discussed in GH issues in the past, but can't find any open ones now. It may also have been only mentioned while trying to profile existing slowness issues. I stumbled upon this again recently when looking into tests/ui/try-trait/deep-try-chain-issue-153583.rs, where the slowest query is <unknown>.

> rm *.mm_profdata ; rustc +nightly -Zself-profile tests/ui/try-trait/deep-try-chain-issue-153583.rs ; summarize summarize *.mm_profdata | head -n 5

error[E0277]: the `?` operator can only be applied to values that implement `Try`
 --> tests/ui/try-trait/deep-try-chain-issue-153583.rs:6:5
  |
6 |     0?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????...
  |     ^^ the `?` operator cannot be applied to type `{integer}`
  |
  = help: the nightly-only, unstable trait `Try` is not implemented for `{integer}`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0277`.
+------------------------------------------------------+-----------+-----------------+----------+------------+
| Item                                                 | Self time | % of total time | Time     | Item count |
+------------------------------------------------------+-----------+-----------------+----------+------------+
| <unknown>                                            | 1.55s     | 99.416          | 3.21s    | 15230      |
+------------------------------------------------------+-----------+-----------------+----------+------------+

This PR fixes that case at least. In general, it should fix the invalid profiling records for fatal errors happening while a query is running.

+------------------------------------------------------+-----------+-----------------+----------+------------+
| Item                                                 | Self time | % of total time | Time     | Item count |
+------------------------------------------------------+-----------+-----------------+----------+------------+
| typeck_root                                          | 5.04s     | 95.588          | 5.08s    | 1          |
+------------------------------------------------------+-----------+-----------------+----------+------------+

r? @bjorn3