core: Add BlockInsertPoint to simplify the builder API

[math-fehr]

Stacked PRs:

• core: Deprecate methods that should be using BlockInsertPoint #3705
• core: Refactor some methods using BlockInsertPoint #3704
• ->core: Add BlockInsertPoint to simplify the builder API #3703

---

core: Add BlockInsertPoint to simplify the builder API

BlockInsertPoint acts the same as InsertPoint, but for blocks.
Its equivalent in MLIR is Block::iterator.

[alexarice]

Could InsertPoint and BlockInsertPoint be a generic class instead? They superficially look very similar except for some types.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.25%. Comparing base (6b2b23c) to head (84b071f).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3703      +/-   ##
==========================================
+ Coverage   91.23%   91.25%   +0.01%     
==========================================
  Files         459      459              
  Lines       57307    57351      +44     
  Branches     5532     5533       +1     
==========================================
+ Hits        52286    52333      +47     
+ Misses       3594     3593       -1     
+ Partials     1427     1425       -2     

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

[compor]

LGTM modulo the missing tests.

[math-fehr]

Could InsertPoint and BlockInsertPoint be a generic class instead? They superficially look very similar except for some types.

I can make them generic, I am just a bit scared of what the documentation will look like.
As you want, I can make it generic now, or later as well

[alexarice]

Maybe just leave it as is. The documentation is important

[alexarice]

Couple of points that don't need to be dealt with in this PR:

• Should InsertPoint be renamed to OpInsertPoint?
• Is it possible/preferable to make the initializer private and force the use of the static methods to construct both InsertPoints and BlockInsertPoints, letting the runtime check be dropped?

[math-fehr]

Should InsertPoint be renamed to OpInsertPoint?

Yes, I think we could rename InsertPoint to OpInsertPoint later on (even if MLIR names it InsertPoint).

Is it possible/preferable to make the initializer private and force the use of the static methods to construct both InsertPoints and BlockInsertPoints, letting the runtime check be dropped?

I never found an actual way to make Python constructors private, which otherwise yes that would make things much better.