(closes #3325) Improving .datatype to return size intrinsics instead of DEFERRED

[LonelyCat124]

Still in progress, this so far changes the arrayreference datatype to never give shapes with ArrayType.Extent in the result if we can resolve the shape.

I want to look at binaryoperation and how it chooses what result to use next, as I think we can do better than the current resul.

[LonelyCat124]

Waiting on coverage to come back, but if its ok this is ready for a first look.

I'm not totally convinced by the choice I make in BinaryOperation, so if the reviewer has a better strategy I'm happy to change it.

StructureReference already did output sizes better than ArrayReference, so from my experiment I didn't think that needed to be updated.

[sergisiso]

I am happy to review this, as I have been thinking what I need to redo WHEREs and it will be something similar. (I will wait for test/coverage to be reported before starting)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.95%. Comparing base (274faab) to head (dfb7589).
⚠️ Report is 23 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3336   +/-   ##
=======================================
  Coverage   99.95%   99.95%           
=======================================
  Files         386      386           
  Lines       54175    54181    +6     
=======================================
+ Hits        54153    54159    +6     
  Misses         22       22           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sergisiso]

Looks good @LonelyCat124 (although I am not convinced about the new special case - see inline)

I see this is a towards, is the goal of that issue to make "the datatype method should not propagate the DEFERRED attribute when constructing the datatype of an expression". Where are we on this?

[sergisiso]

Oh and I forgot about the Coverage indirect changes. It seems they are related to WHEREs, so I would address that comment first and see if they are still there.

[LonelyCat124]

@sergisiso Ready for another look now I've updated the array_mixin stuff.

[sergisiso]

@LonelyCat124 I was almost ready to approve it but I don't understand one of the tests. Could you have a look?

Also, is there anything pending to close the associated issue?

[LonelyCat124]

@sergisiso Ready for another look, I'm going to set the CI going now.

[sergisiso]

@LonelyCat124 All comments have been addressed. Nicely done simplifying in the frontend and letting more cases output literals instead of intrinsics.

I expect some conflicts with the PR that is marked as "Ready to be merged" but since this are partially my fault, I will mark this one as approved and resolve the conflicts myself.

[LonelyCat124]

Yeah I just want to make sure the latest changes didn't break anything in the CI that I didn't understand