Make Grid.coord_iter return content, pos

[Tortar]

All the examples which use coord_iter transform the output so that to have a pos tuple, this should be avoided, right now I changed coord_iter, so this is a breaking change, but we can even (probably better) deprecate this method and create a new one with a new name, what do you suggest as new name @rht, @Corvince? pos_iter?

[Tortar]

also we can do inside something like return zip(iter(self), itertools.product(range(self.width), range(self.height))) which should be faster

[Tortar]

ok done this way, because seems much better, still need to change/add some tests and maybe the deprecation and changing the name if you have any suggestion

[codecov]

Codecov Report

Base: 82.05% // Head: 82.00% // Decreases project coverage by -0.04% ⚠️

Coverage data is based on head (daf0e84) compared to base (fc013ab).
Patch coverage: 50.00% of modified lines in pull request are covered.

❗ Current head daf0e84 differs from pull request most recent head 5111908. Consider uploading reports for the commit 5111908 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1566      +/-   ##
==========================================
- Coverage   82.05%   82.00%   -0.05%     
==========================================
  Files          18       18              
  Lines        1382     1384       +2     
  Branches      270      270              
==========================================
+ Hits         1134     1135       +1     
- Misses        204      205       +1     
  Partials       44       44              

Impacted Files	Coverage Δ
mesa/space.py	91.04% <50.00%> (-0.22%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[rht]

We probably should just do a breaking change to coord_iter itself in Mesa 2.0. Adding methods is costly and people can get confused by the plethora of methods.

[Tortar]

Agree, all should be ok for merging in 2.0. :-)

[rht]

Redone in #1723, because handling the merge conflict takes longer.