Separation between MemorySegment and MemoryScope

[Maurizio Cimadamore]

Some of the consideration (see below) are correct John, but here the 
choice is not between the choice you picture - e.g. "safe-but-slow vs. 
fast-but-unsafe".

If you construct a memory segment, w/ or w/o explicit parameters, you 
always get a safe memory segment, and actually, unless I'm mistaken, the 
speed won't really change by much (I believe they all perform the same now).

The choice here is whether to make implicit GC allocation the default or 
not (the current API says yes, partly out of a desire to offer 
ByteBuffer users a relatively gentle ramp).

But, I must stress, whether you chose one or the other _the segment you 
get back is still safe_.

> So, make it explicit.

I might agree with this, and what Remi proposed earlier, but for more 
pragmatic reasons: when using the API, I found that the current API 
makes it perhaps a little too easy for the user to "forget" about the 
scope argument - example:

```
try (ResourceScope scope = ResourceScope.ofConfined()) {
    // ok I have a scope here
    MemorySegment segment = MemorySegment.allocateNative(100); // bug??
    ...
}
```

The call to MemorySegment::allocateNative is missing the scope parameter 
which, because of the overloads, is effectively an optional parameter. 
This might mean that developer might sometime get GC deallocation 
semantics "accidentally" (it happened to me on a couple of tests and 
jextract samples, so I have to conclude that this can happen to other 
folks too).

To me, that is the most compelling argument in favor of removing the 
default: e.g. extra overload don't buy you that much (e.g. you can have 
a  more aptly named `gcScope` factory which gives you the current 
default), and it introduces potential for mistakes. Since the cost for 
going explicit here is fairly low, I can see the argument.

Maurizio