[mlir][Pass] Make PassManager default to op-agnostic

[rkayaith]

Summary

Currently PassManager defaults to being anchored on builtin.module.
Switching the default makes PassManager consistent with
OpPassManager and avoids the implicit dependency on builtin.module.

Specifying the anchor op type isn't strictly necessary when using
explicit nesting (existing pipelines will continue to work), but I've
updated most call sites to specify the anchor since it allows for better
error-checking during pipeline construction.

[rkayaith]

fix for doc change

[rriddle]

mlir/include/mlir/Pass/PassManager.h

211–220

Can you add a utility template class that takes the operation type? It'd be nice to preserve the simplicity when the anchor type is known (common for real pipelines), e.g.:

template <typename OpType>
class PassManagerOn : public PassManager ...

That would remove the need for most of the "dialect.opname"/"Op::getOperationName()"/"getName" calls when building a known passmanager.

[rkayaith]

add PassManagerOn class

[rkayaith]

mlir/include/mlir/Pass/PassManager.h

211–220

I added this + ModulePassManager as an alias, though I think there's a potential footgun since it's possible to change the anchor after the pass manager is created, e.g. https://github.com/llvm/llvm-project/blob/ecab1bc0dcdc04ec863f7aa3eaa5daad8232ba65/mlir/lib/Pass/PassCrashRecovery.cpp#L477-L480

[rriddle]

mlir/include/mlir/Pass/PassManager.h

211–220

Good point there. We could have a run method in PassManagerOn that verifies that the anchor is actually correct. We could also just have a templated construction method that returns a pass manager? Just making sure we don't lose the niceties of the API when we don't want "any" anchor.

458–459

I'd just drop any special usings for ModuleOp, it helps keep the API free from builtin deps.

[rkayaith]

I plan to rebase this + switch to a constructor method (static PassManager::on<T>(MLIRContext*) -> PassManager)

[rkayaith]

Switch from PassManagerOn<T> to constructor method