[CI] Track LLVM Changes hits time limit (6h)

[dtzSiFive]

e.g., https://github.com/llvm/circt/actions/runs/6043597331

Current run presently has 30 minutes but probably won't make it either: https://github.com/llvm/circt/actions/runs/6048085800/job/16412795947 .

If the bisect hits the time limit in the interesting cases, may not be worth running this (beyond tracking that something broke?).

Other solutions too, WDYT?

[teqdruid]

If we continue to run it (I've found it useful in the past), we can turn on ccache. Might help some within a run and would (if the cache entry isn't evicted) help the night-to-night runs.

[dtzSiFive]

This workflow was removed in #6306 -- which claims it was disabled for some time.

I'm not sure I see that to be the case (?), and we still link to it from our README (an easy fix if we don't want it anymore).

Any preferences on restoring this workflow (as it was, not proposing any changes to it presently)?

[seldridge]

I'd suggest moving this to a slightly different model based off of how I've gotten CIRCT CI/CD working for downstream projects, e.g., Chisel:

1. There is a permanent "staging branch" that is where any accumulated changes for the next bump live.
2. Every night, the "staging branch" is updated to try to work with latest upstream LLVM.
3. If this fails, if just fails and notifies people who care.
4. We then PR against the staging branch to get it working with LLVM.
5. Every week, there is a CD run that PRs the staging branch against main.

Naturally, (5) can be triggered manually. Also, the "staging branch" can e a permanent PR of sorts to avoid a weekly timer on when a new PR is created.

tl;dr: I'd treat this more as a CI/CD problem of how do we automatically deliver a new upstream LLVM version into CIRCT and what are the requisite CI checks to know if this is going to work.