Improve Apollo 4 error capturing

[lcian]

Description

The Apollo 4 migration guide mentions that "fetch errors like network errors, cache misses, and parsing errors [...] are now surfaced by returning (for execute()) or emitting (for Flows) an ApolloResponse with a non-null exception instead of throwing it".

We are currently using the same logic for Apollo 4 as for Apollo 3.
We should investigate in which specific cases this field is set and if the SDK is behaving correctly in those cases (sending an error or a warning/error level breadcrumb).

After some preliminary tests, it seems that the logic for Apollo 3, without special handling for the new exception field, leads to the same behaviour of the SDK for Apollo 4 as for Apollo 3, as in both cases we can tell if an operation failed by the presence of the errors field in the response body or by looking at the HTTP response code.

[markushi]

Let's not forget to update our docs for Apollo 4 support.

[kahest]

related: #3662