[llvm] [mlir] Split the llvm::ThreadPool into an abstract base class and an impleme… (PR #82094)

[Mehdi Amini via llvm-commits]

joker-eph wrote:

> I'd probably use ThreadPool as the name for the interface, and rename the current implementation to DefaultThreadPool or StdThreadPool or BasicThreadPool or the like?

That's a good point, and actually I think I considered it but it's also a much larger breaking changes: right now the refactoring would not break any user, while the renaming would require every place that instantiate a `ThreadPool` class to be updated.
(I don't mind the mass rename though, it's scriptable)

> It might also be an opportunity to simplify the current macro and other checking for whether multithreading is enabled - we could have an UnThreadPool that's just single threaded, and use that when threading is disabled?

That would percolate into every single caller though? Right now the `ThreadPool` class is instantiated in various places, and the implementation manages.
How would you envision it if there was a `UnThreadPool` class?

https://github.com/llvm/llvm-project/pull/82094