dialects: (csl) handle negative-valued task ID representation

[superlopuh]

i6 and friends are signless, meaning that they are bitpatterns that don't have an inherent value. When printing CSL, we currently take the raw data of the IntegerAttr, but it seems like that's not valid for task identifiers, which are positive. This PR changes the printer to always print the unsigned version of the number, and adds a test case to the CSL filecheck.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.40%. Comparing base (92101f8) to head (f96897a).
Report is 10 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #3558    +/-   ##
========================================
  Coverage   90.39%   90.40%            
========================================
  Files         466      467     +1     
  Lines       58722    58843   +121     
  Branches     5593     5603    +10     
========================================
+ Hits        53083    53196   +113     
- Misses       4204     4205     +1     
- Partials     1435     1442     +7     

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

[dk949]

I think this makes sense, even if it is really odd to see a negative task ID in the IR.

As a sidenote, it would've probably been better to have made this an i16 and dealt with the range in the verify

[superlopuh]

There are probably a few things to do, and making it an unsigned integer is also an option, especially if you'll not do any more arithmetic with it once you pin it down. If you'd like, I can do that in this PR instead?

[superlopuh]

I decided to try it out, happy to revert to previous version if you'd like to keep the IDs signless.

[n-io]

Looks good, @dk949 ?

[dk949]

I like this, it exactly expresses the constraints on these values in the types.