Python 3.10 compatiblity fixes

[k-dominik]

One of our test configurations picked up Python 3.10 (which is fine for the "lirbary" usage). This resulted in some minor errors:

1. Threadings condition.notifyAll has been marked for deprecation in favor of condition.notify_all. In TestCompatibilityChecks.test_access_opaque_slot_value_should_not_warn_or_raise we check that no warning is raised. This was of course broken by the deprecation. Rather than adapting the test I preferred keeping up with Python
2. Python stopped implicitly converting types in function calls -> results in errors/segfaults in pyqt. Explicitly converted types or made sure e.g. integer value division is used (e.g. in draw methods of featureTableWidget).

fixes #2852

[codecov]

Codecov Report

Attention: Patch coverage is 68.42105% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 55.96%. Comparing base (1df74b8) to head (a51c4c1).

Files	Patch %	Lines
ilastik/widgets/featureTableWidget.py	60.00%	2 Missing ⚠️
ilastik/widgets/preView.py	66.66%	2 Missing ⚠️
...stik/applets/counting/countingGuiBoxesInterface.py	0.00%	1 Missing ⚠️
lazyflow/operator.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2856      +/-   ##
==========================================
+ Coverage   55.95%   55.96%   +0.01%     
==========================================
  Files         533      533              
  Lines       62300    62293       -7     
  Branches     8549     8548       -1     
==========================================
+ Hits        34859    34865       +6     
+ Misses      25684    25675       -9     
+ Partials     1757     1753       -4     

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

[btbest]

Nicely tracked down 🫡 This means these bits of code actually weren't python3.10 compatible this whole time..?

There are three drawEllipse calls in the codebase that use old_div and could hence pass floats to the Qt function (which I assume now only works with int); featureTableWidget.py:174 and two in preView.py.

I suppose to be absolutely sure, one would have to explicitly int() the division results as well, since 6//2.0 is 2.0, but I think we'll be fine assuming that we're only passing ints into those divisions into the first place.

[k-dominik]

There are three drawEllipse calls in the codebase that use old_div and could hence pass floats to the Qt function (which I assume now only works with int); featureTableWidget.py:174 and two in preView.py.

ok - I will make those old_div -> // as well for better consistency, too, thank you for pointing to that.

The type annotations for pyqt help a lot with the int issue - so in most cases pyright tells me it's allright without casting. But yes, to be super sure we could cast (but I'd like to avoid this noise, as it's also sends the message that we don't trust the type annots)