Following JDK-8249879, the state of struct fields address accessors generated by jextract is less than ideal.

For instance, if a struct has a field bar, jextract will generate the following accessor:

MemorySegment bar$addr(MemorySegment segment) {
   return segment.asSlice(<offset of bar>);
}

This is suboptimal for a number of reasons:

1. The name "foo$addr" doesn't reflect what the accessor is really doing
2. since the accessor slices the original segment, closing the returned segment will also close the original one - but that's not easy to follow, since the slice is created by jextract

I think it would make more sense if, instead of having the jextract API perform slices, we'd simply had the API return the various field offsets - in other words, let's just have a simpler:

bar$offset -> long

And then leave slicing to the user. This brings more clarity in the user code, and it is also better in the sense that the user might use the offset for other tasks (e.g. compute a dereference offset).

While the offset is derivable from the layout API, in this case it seems a no brainer to expose offset accessors, given that all the info to compute such offsets is known statically.

As for global variables, perhaps we should rename global$addr into global$segment, and make sure the returned segment is not closeable.