Remove suspend modifier from ResourceScope.onRelease

[kyay10]

This allows it to be called in non-suspending contexts like runInterruptible which is important for resource safety when interacting with interruptible Java APIs. It also just doesn't need to be suspend, and in fact, it can be the SAM that defines ResourceScope, although that's not implemented here.
This is the only binary breaking change needed for #3518.
I'd really like to get this approved for 2.0, since otherwise we'd have to delay it to 3.0 :(

[github-actions]

Kover Report

File	Coverage [70.24%]
arrow-libs/fx/arrow-fx-coroutines/src/commonMain/kotlin/arrow/fx/coroutines/Resource.kt	70.24%

Total Project Coverage	46.07%

[serras]

Note that the current architecture is that anything which does not collaborate with coroutines (including Java interop) should go to arrow-autoclose, and Resource should build on top of that to include integration with coroutines. There are some cases where the compiler suggests dropping suspend, but we still want to keep it to signal that this is only for coroutines.

By the way, is this something that should also be in AutoClose? The overall idea is to align the two APIs as much as possible, except suspend and other coroutine-related elements.

[kyay10]

Oh sorry let me clarify: this is Java interop with coroutines. runInterruptible is a kotlinx.coroutines function that interops with Java, but it's just one example of a use case where you want to call onRelease without being able to suspend. onRelease is specific to Resource because it has to support suspending release handlers.
AutoCloseScope I think doesn't currently have an onRelease analog. I'm adding one though in the aforementioned PR under the name onClose. I don't think adding onClose in this PR is important though, since it's a trivial addition and doesn't break any compatibilities.

[serras]

Ah, I misunderstood where the suspend is being removed (I thought it was from the argument). If in the new implementation this becomes possible, I would go for it.