[foreign-memaccess+abi] RFR: Refactor compound layouts such as SequenceLayout and StructLayout [v2]

[Maurizio Cimadamore]

On Tue, 13 Sep 2022 12:30:33 GMT, Per Minborg <duke at openjdk.org> wrote:

>> This PR proposes harmonizations between `SequenceLayout` and `GroupLayout` as well as some improvements to the API exposing fewer details.
>> 
>> In this PR, there is an extra level that unifies and deduplicates the common methods in Sequence and Group Layouts. This level is visible in the sealed hierarchy. It would be possible to make it a separate interface that is not in the sealed hierarchy as an alternative.
>> 
>> ![graphviz (23)](https://user-images.githubusercontent.com/7457876/189898114-b1fc8a44-7ce0-43ad-a82e-d62b3ce0e110.svg)
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert name of GroupLayout implementation

src/java.base/share/classes/java/lang/foreign/CompoundLayout.java line 6:

> 4: import java.util.stream.Stream;
> 5: 
> 6: /**

I believe there's no reason to keep both CompoundLayout and GroupLayout in the public API, since they are both umbrellas for the same sets of public types (for now at least). I think we can just move these methods down to `GroupLayout` and remove `CompoundLayout`.

It's true that a `SequenceLayout` can also be viewed as a compound layout with the elements replicated N times, but, I'm having an hard time as to why a client would e.g. treat a SequenceLayout as an Iterable. I think SequenceLayout should mostly stay as is for now. As long as the `elementCount` name matches, we have room at a later point (if we so decide) to bring `SequenceLayout` under `GroupLayout` (or under some other common supertype).

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

PR: https://git.openjdk.org/panama-foreign/pull/719