Remove creation of subrow from ReportQueryResult for batchfetch performance

[Sheikah45]

This is a follow up to #2303. After some additional testing I observed some performance degradation when using batchfetch in with a ReportQuery. The degraded performance occurred when the item being constructed did not have the first index in the row. In this case a subrow was created that contained only the fields after the item index. When a batchfetch policy was in use this also required performing the same action on all the rows returned by the query and setting them for the data results in the batch fetch policy for the item's mappings as they would be used in the ForeignReferenceMapping to extract the required keys.

This caused every subrow to have to be created for every item even if it has been previously done because the rows use identity based equality. After looking through the downstream uses of the subrow it is not clear why this trimming is necessary. For the downstream object building values are extracted using their corresponding field references rather than by index in the row.

For this reason I have removed the creation of the subrow altogether but am also curious what the original reason for the subrow was and if this may have other performance implications for downstream processing of the row.