Add generic handling of JSON:API includes

I've created POC code.
However, due to downtime of the API I'm using and looming weekend this hasn't been tested.
But I thought this at least provides something do talk about if this is an interesting proposal.
Alternatively, I'll add it via a custom StorageClient plugin - easy enough to do so :)

I've been chipping away on this and realized that \Drupal\external_entities\Plugin\ExternalEntities\StorageClient\JsonApi does some very interesting things with the results fetched in order to extract the included data via JsonPath.
That interesting way works for single item load, but was lacking querySource support.
That lead to the fact that only the first source of vertical data aggregators had included data present to use - which then leads to inconsistencies inbetween storage clients which might break the field mappings.

After looking deeper into that I think \Drupal\external_entities\Plugin\ExternalEntities\StorageClient\RestClient::querySource() might does to much - making it not as extensible as needed. The classes inheriting it only have access to the results after major parts of the parsing has been done. It probably would be more flexible to split the method up into communication with the endpoint the pure data fetch, and then processing of the fetched data.
Another option I see right of the bat is to add a custom Decoder based on \Drupal\Component\Serialization\Json. That way JsonApi would have access to the raw response, can decode and decorate it as needed without any "hacks" to access & collect the data.

I hope it is not a high priority for you nor urgent as I don't have time currently to review this feature request... :s
I'm not against the idea of splitting Rest client functions into pieces though. I would need time to read carefully what you put and understand what is your final goal and then I could have an opinion.

@guignonv No worries, no rush. I can use the patching system or in the worst case I'll implement my own external entities client.
But my goal is to provide a json:api, specifically a Drupal json:api specific, integration that is as optimized and as easy to use as possible.
This FR essentially only expands on the handling of the "included" properties as it was available for single load events: https://git.drupalcode.org/project/external_entities/-/blob/2d5693e4a0af...

In order to be consistently usable that handling has to be available across all query types single, multi, filter etc.
To do so I've now implemented a custom external_entity_response_decoder - this allows a much cleaner handling of the raw response data across all query types.

On top of that the new handling addresses the limitations of JsonPath. With the current limitations it's not possible to resolve multi value relationships. My approach to this is to not just pack "included" into each result item, but inject the related include straight into the relationship referencing the data - essentially just a denormalization in order to keep access to the referenced data as simple as possible.

Have been using the adjustment for a while and it seems to do it's job: Keeping the JSON that is evaluated consistent across all types of requests.
Hence setting this to needs review.

Code looks good. I also enjoy the use of custom response decoder as it gives an example of using custom response decoders in external entities. I need to test it though... I'll do my best.

I'm wondering though if it could have been achieved using data processors. But I need to test to really understand the problem when facing data and not theory! ;-p

Also, I need to make sure it will work the way "reverse", when you need to save external data. I'm not sure it does... :-s