Don't hold the PatternCache lock while freezing the patterns.

[lupalby]

What

PatternCache::get held mutex_ across the FrozenRewritePatternSet
construction. This narrows the lock to the map accesses and builds the frozen
set with it released.

Why

Freezing a PDL module runs a pass manager of its own, which hands its parallel
verifier to the MLIRContext's thread pool and waits for it. And
apply-device-patterns is nested over modules and then functions, so MLIR's
asynchronous pass adaptor runs it on that same pool, many at once, all sharing
the one PatternCache the device holds.

StdThreadPool::processTasks(WaitingForGroup) wakes on !Tasks.empty() and
then pops Tasks.front() regardless of which group that task belongs to. So a
pool thread waiting for its own group picks up a sibling function's run of this
pass and stops on this lock -- and is then no longer available to finish the
group the lock's holder is waiting for. Once every thread that could have
finished the freeze is stopped on the lock, nothing finishes and the compile
hangs.

The two shapes seen together in one hung process:

holder:   PatternCache::get (holds mutex_) -> FrozenRewritePatternSet
                                          -> PassManager::run -> verify
                                          -> processTasks         <- waiting on the pool
blocked:  processTasks -> verifyOpAndDominance -> processTasks     <- waiting on its own group
                      -> stolen adaptor task  -> PatternCache::get <- parked on mutex_

SmartMutex<true> being recursive kept this quiet rather than loud: in one
capture the holder had stolen a sibling task, re-entered its own lock, found the
cache still cold and started rebuilding the whole set on top of itself -- two
nested PatternCache::get frames in one stack.

Cost

Two callers that miss together now build a set each, and the first one back
files it with try_emplace while the others take that, so every caller still
gets one set. Building concurrently is safe: getPatterns only reads the device
and clones into a module of its own.

Testing

Reproduced and measured on a downstream MLIR pipeline that runs this pass over
several modules, each holding one function. The failure is a hang until the CI
timeout, on a different test each time, so it is measured as a hang rate over
repeated runs of one suite rather than as a single pass/fail. Same harness, two
uninstrumented builds:

build	suite runs	hung
before	15	2
after	30	0

Every test passed on every run of the fixed build.

How likely it is depends on how close the pool is to saturation. Widening the
lock window with a sleep does not reproduce it on a 64-core machine, because
idle workers are always left to finish the group; fewer cores makes it more
likely, which is why CI sees it more often than a workstation does.

No regression test: a reappearance shows up as a CI timeout rather than a test
failure, and the interleaving is not reliably forceable.

Follow-up

mutex_ could become non-recursive now that nothing is held across the freeze.
Nothing needs the recursion, and a non-recursive mutex would have made this an
immediate, obvious failure instead of a hang once in several runs.

[KFAFSP]

I had removed the lock once before and was still able to trigger a race, maybe I did something else wrong. Still, if this works for you, LGTM.