Fix 0-Hamming-weight edge case

To date, maxcut_tfim(G) variants have excluded 0 and maximum Hamming weight after finite-difference adiabatic TFIM simulation and renormalized. The reasoning was that these were single, trivial cases, with bipartition between all nodes in one subset and empty set for the other, and it was easy for users to check the single case, while any probabilistic sampling of these cases would therefore be a waste. However, it occurred to me, there's not even a cut-verification cost to checking these cases: they necessarily imply a cut of 0.0, so they should preempt any results returned with negative cut values, always, for the cost of a single conditional check against the best returned cut value. Hence, we reinsert this edge case, whenever best cut value is negative. (Interestingly, because Hamming weights of 0 and maximum value are excluded anyway as explained above, if there is any degeneracy to 0-value cuts, like for block-wise sparse test cases with all negative nonzero weights, the solver tends to prefer to return the nontrivial partition cases with 0-value cut. Since this is potentially useful information, we leave this behavior in, simply by excluding override comparison equality for 0.0 limit point.)

Full Changelog: v8.7.1...v8.7.2

sha1sum results:
4f6f13354f6acb65e2c113d128a59ad238ac3147 pyqrackising-8.7.2-cp310-cp310-manylinux_2_35_x86_64.whl
51c2a9cebe13e01f00a6f9270c022e5ec7175bac pyqrackising-8.7.2-cp312-cp312-manylinux_2_39_x86_64.whl
7e614026ff4868e7950d436116a6953c4c4e23c8 pyqrackising-8.7.2-cp312-cp312-win_amd64.whl
cf596c0be12325ff8acef742575036117db21792 pyqrackising-8.7.2-cp313-cp313-macosx_14_0_arm64.whl
8f9189e0a8e1ac11f8088848b8e9f78584777d3f pyqrackising-8.7.2-cp313-cp313-macosx_15_0_arm64.whl
fb3f11aa2b88e69dffd712b12fa6ddf11e741309 pyqrackising-8.7.2.tar.gz