We need to be more explicit about the Cats Effect memory model

Currently the Cats Effect memory model is implicitly defined via implementation details and the Java Memory Model (JMM). In some cases this works okay but in other cases this means that our memory model is effectively undefined.

As a concrete example, earlier today on Discord there was a report that Semaphore offers no memory ordering guarantees when acquiring/releasing 0 permits. This boils down to a specific implementation detail that doesn't matter if you are using CE's own concurrency primitives and data structures, but matters a lot if you are reading/writing unsynchronized memory unsafely with delay. We can't say if the current Semaphore implementation is bugged or not without explicitly defining the expected semantics.

With Scala Native multi-threading on the horizon in https://github.com/typelevel/cats-effect/issues/3662, nailing down the specifics of the CE memory model becomes even more important since we have a lot more flexibility in implementation details. Longer-term, Scala Native could potentially even support weaker memory models than the JMM.[^1]

[^1]: Tangential, but I have a hypothesis that code written using immutable data structures and CE concurrency primitives actually does not need many guarantees of the JMM (e.g. publication of final fields on construction) and that a weaker CE memory model would be sufficient and have better performance esp. on ARM.

Start with the linked Semaphore implementation around line 176 and the discussion of the Java Memory Model in this issue. Read issue #3662 for the Scala Native context, then review the reported zero-permit Semaphore behavior. Done means the Cats Effect memory model and its expected ordering guarantees are explicitly defined, including whether the cited behavior is a bug.