transformations: Implement shape-inference pass

[PapyChacal]

Implement a trait-based generic shape-inference pass, following the style of canonicalize, allowing for shape inference patterns to interoperate amongst dialect and all; Just hook existing stencil shape inference patterns in there for now.

Stacked on:

• transformations: stencil shape inference polish #3046

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.89%. Comparing base (5568380) to head (1f7b66a).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3047   +/-   ##
=======================================
  Coverage   89.89%   89.89%           
=======================================
  Files         415      416    +1     
  Lines       52120    52173   +53     
  Branches     8060     8063    +3     
=======================================
+ Hits        46852    46903   +51     
- Misses       3976     3977    +1     
- Partials     1292     1293    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[superlopuh]

Very nice! When I did this in the Toy tutorial, I followed the MLIR version's approach of just modifying the type directly, instead of using a rewrite pattern: https://mlir.llvm.org/docs/Tutorials/Toy/Ch-4/
I'm now not sure which approach is prefereable. It feels like the one used in Toy is more straightforward, why not use that directly?

[PapyChacal]

Very nice! When I did this in the Toy tutorial, I followed the MLIR version's approach of just modifying the type directly, instead of using a rewrite pattern: https://mlir.llvm.org/docs/Tutorials/Toy/Ch-4/ I'm now not sure which approach is prefereable. It feels like the one used in Toy is more straightforward, why not use that directly?

I belive it's less generic, right? I need some level of worklist management for my pass to work independently of the application order. stencil shape inference also works backwards, inferring operand sizes from results. So to interoperate both direction, I think we need that?

I would argue for sugar to hook a simpler case like the Toy one in the bigger case if you really want to keep Toy simple yet integrate in this one. I also think it might be okay to just have a simple one on Toy for demo purposes, and it doesn't have to imply constraints on the core one?

[n-io]

Looks great, thanks