Add Reentrantlock

[regiskuckaertz]

Closes #5807

Is this still relevant? I tried to stick to the java api as much as possible, though I think interruption is so central to zio that it did not make much sense not to handle it by default. Let me know what you think.

[regiskuckaertz]

@adamgfraser hello 👋 if you're happy with that I can port to the 2.x branch afterwards.

[adamgfraser]

@regiskuckaertz Will take a look today!

[adamgfraser]

This looks good. I think the big question here is whether we want this to be its own bespoke data structure or a type alias for the existing TReentrantLock similar to what we did with Semaphore and TSemaphore.

[regiskuckaertz]

Yeah I thought about that, I wasn't really sure what to do tbh, but happy to do it that way instead. Is it still the intent to match the JDK API or not?

[adamgfraser]

I think if we did that we definitely wouldn't match the Java API. My initial thought would have been to just alias TReentrantLock but since we have already done the work on this happy to go either way.

[regiskuckaertz]

I'm tempted to say on the surface the datatypes in zio.concurrent currently are very close to the jdk, and that using STM under the hood feels like an implementation detail. Can we go that way and see how it pans out?

[regiskuckaertz]

@adamgfraser ping 😇

[adamgfraser]

@regiskuckaertz Sure!