Temporarily disable building rustc with ThinLTO on x86_64-unknown-linux-gnu and x86_64-pc-windows-msvc

[lqd]

Context: we recently started building librustc_driver.so with ThinLTO on:

• x86_64-unknown-linux-gnu in Enable LTO for rustc_driver.so #101403, nightly-2022-10-24
• x86_64-pc-windows-msvc in Enable ThinLTO for rustc on x64 msvc #103591, nightly-2022-12-12
• x86_64-apple-darwin in Enable ThinLTO for rustc on x86_64-apple-darwin #103647, nightly-2022-12-12

Unfortunately, it appears to regress the message we print during ICEs sometimes, including the query stack and explanation on how to open a GH issue. This was noticed in #105637 on mac (where I've enabled ThinLTO recently, and why I was pinged because of the regression and started looking into this), but is present on all the above targets today. There's also a summary and examples in that issue here and some more discussion in this zulip prioritization topic.

Since this is useful information for reporting issues, triage and bisections, it impacts the quality of bug reports. The issue was deemed P-critical, so this PR works around it by temporarily disabling ThinLTO on linux/windows (this setting is already being temporarily disabled for mac as well in #105646) until we can fully investigate and fix the underlying issue causing this early abort (e.g. some UB somewhere causing problems now because of the newly enabled optimizations).

Since this issue impacts the quality of bug reports, it could be more important than the perf ThinLTO provides. I don't have the time to fully investigate the cause right now, but maybe someone else does. (I believe we'd rather workaround the issue than live with it ?)

To that end, I'll cc:

• t-compiler leads @pnkfelix and @wesleywiser on: whether this workaround is the approach we want to take, and if the issue/PR should be nominated for discussion at the next t-compiler meeting, if anyone from the team would be available/willing to investigate, etc
• the prioritization working group @rust-lang/wg-prioritization
• the authors of this original work, @bjorn3 and @Kobzol

(Note: #101403 will land in 1.66 on 12/15 in 2 days, but rebuilding stable artifacts this late was deemed not worth it in the zulip topic linked above)

(Opening as draft to not merge early)

[rustbot]

r? @jyn514

(rustbot has picked a reviewer for you, use r? to override)

[lqd]

(apologies to joshua for the unexpected ping, I forgot to r? @ghost)

@bors try

[lqd]

@bors ping

[bors]

😪 I'm awake I'm awake

[lqd]

@bors try

[lqd]

@bors try

[Kobzol]

Seems like bors doesn't want to part with LTO perf. gains :)

[lqd]

@bors try

[bors]

⌛ Trying commit 548cc35 with merge 935dcc042c9966d1b4d4ee6c6cd3f528c1fe3ed9...

[bors]

☀️ Try build successful - checks-actions
Build commit: 935dcc042c9966d1b4d4ee6c6cd3f528c1fe3ed9 (935dcc042c9966d1b4d4ee6c6cd3f528c1fe3ed9)

[lqd]

I believe #105800 fixed the underlying issue, so this workaround shouldn't be needed anymore.