performance-test: suggest a more comparable loading time for non-eager and eager execution

[dafnapension]

Currently, Load Time reported in the performance test summary is the cumulative time spent in loader.load_data() . This is good for all types of loaders.
However, still within Loader.load_data(), immediately following the download of the dataset (from HF, for example, in case of LoadHF), comes MultiStream.from_iterables, the first introduction of the downloaded data into unitxt's recipe. In this introduction, eager-execution differs in its action from non-eager-execution:
In eager-mode, unitxt loops over each and every instance, to include it into the ListStreams constituting the MultiStream being generated. Whereas in the non-eager mode, unitxt just creates generators, for the GeneratorStreams constituting the MultiStream generated in this case, and returns from load_data().

Now, with load_iterables recently introduced into loaders.py by @elronbandel , we can clearly fetch net load time of datasets, excluding the introduction of each and every instance into unitxt that is only done in eager mode.

Here are demonstrating snakeviz-s:
For eager mode, more time is spent in Loader.load_data() than in LoaderHF.load_iterables:

Whereas for non-eager mode -- the same (the time to generate the generators is unnoticeable):

[dafnapension]

Hi @elronbandel ,
I am not sure how important is the issue raised here. We usually compare performance of PR against main either when both are eager or both are non-eager, so why bother. On the other hand - why not be accurate, and have each mode 'pay' for its going over the fresh instances in its reported Net Time. What is your view about this?