[foreign] musing on segment spliterators

[Maurizio Cimadamore]

Hi,
in the last couple of iterations, we have added ability to get a 
spliterator out of a segment. I think this is an extremely helpful 
feature, which has been made more difficult to use than it needs to be - 
for two reasons which I'll try to outline what I mean in the following.

First, to split a segment you need an "element layout". E.g. you have to 
tell the spliterator logic where the boundaries of the sub-segments are. 
To do this, the current API takes a SequenceLayout. So, assuming your 
segments contains 64 pointers, to get a spliterator you need:

```
segment.spliterator(sequenceLayout(64, C_POINTER));
```

The method throws if the size of the sequence layout doesn't match the 
size of the segment.

So here's the first usability bit: why does the user have to specify a 
sequence layout? That sequence has a parameter (the sequence size) which 
can easily be inferred from the segment size. Why not just:

```
segment.spliterator(C_POINTER);
```

E.g. tell me what your element layout is, and we'll happily split the 
segment for you. As before, if the size of the segment is not a multiple 
of the layout size... exception.

And now, onto the second usability issue - while it is generally 
possible to create streams out of spliterators, that is also a 
verbose-ish way to do things:

```
Stream.of(segment.spliterator(C_POINTER))
```

As opposed to just:

```
segment.stream(C_POINTER)

```

The latter works much better with the chained call that normally arise 
when working with the stream API. Assume that `segment` contains a bunch 
of string pointers - then we can map everything back to an array of 
on-heap strings, as follows:

```
segment.stream(C_POINTER)
        .map(MemoryAccess::getAddress)
        .map(CLinker::toJavaString)
        .toArray(String[]::new);
```

In other words, what I'm trying to say, is that when it comes to perform 
custom data marshalling/unmarshalling, using streams and collectors is 
likely going to be the way to go - so we might just as well make it 
easier for developers to access what, until now, has been sitting in a 
corner of the API.

Thoughts?

Maurizio