[foreign-preview] RFR: 8282626: Revert semantic of session accessors

[Maurizio Cimadamore]

This patch reverts the hook to make session accessors return a non-closeable session view.

This hook makes it harder to use segments that are backed by a one-off session; consider this case:


SegmentAllocator malloc = MemorySegment::allocateNative;
MemorySegment segment = malloc.allocate(100); // no way to close this


In other words, the asymmetry we added to the API requires clients to perform a lot of tracking to be able to associate segments back to their sessions, creating an obvious scalability problem.

Moreover, the existing hook only protects against close. Clients of a segment can still allocate on a session they might not supposed to, or make the session uncloseable, by registering an infinite close action on it.

At the same time, when looking at how sessions might be used by APIs, usage patterns seem to fall in two categories:

* **External scope**. APIs that need to create a resource (e.g. a matrix) will take as input a scope, which indicates the lifecycle associated with the resource they want to create. In this case, securing the scope is not necessary, as the API is getting the scope from somewhere else. It is the *client* of the API that has to trust the API not to mess up with its scope (but if the API does something shady with the client scope, that's arguably a bug in the API). Code generated by jextract falls in this category, as well as [pooled allocators](https://github.com/openjdk/panama-foreign/pull/509).

* **Internal scope**. Some APIs might want to hide scopes from clients; in such cases, the scope will be created in the constructor, along with all the resources associated with it. In these cases, as the API has already provided some encapsulation, it seems sensible for the API to keep encapsulating resources associated with the scope created internally. The code I've seen for both Lucene and Netty falls in this category.

In other words, making memory segments more principled only provides real benefit for APIs that combine both approaches; so far we don't have much evidence that such APIs exist (but if you have some use cases, we'd be interested to know!).

Considering all this, it makes sense to revert the API so that session accessor retain full powers.

This patch leaves the `isCloseable` predicate (still useful to query if a session can be used) as well as `equals/hashcode` (as moving away from `==` will keep our options more open).

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.java.net/panama-foreign/pull/661/files
 Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=661&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282626
  Stats: 284 lines in 30 files changed: 11 ins; 124 del; 149 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/661.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/661/head:pull/661

PR: https://git.openjdk.java.net/panama-foreign/pull/661