Enable stitching of non-sequentially ordered tiles

[federico-carrara]

Problem

Currently, CAREamics only allows to perform either stitching of tiles belonging to a single image (stitch_prediction_single()), or of sequentially-sorted tiles from different images (stitch_prediction()).
However, there are many instances in which tiles may not come in sequential order. For example, think about any multi-processing scenario, in which tiles processed by different workers can be then gathered in different orders.

Potential solution

A possible and not too complicated solution would be to stitch tiles not based on their order, like it now happens, but based on the sample_id attribute of the corresponding TileInformation object. The only thing to carefully decide here is how to assign unique IDs to sample, considering that they may come in different ways. In fact, I see these 3 scenarios to differentiate:

1. tiles coming from a sample coming from a single file,
2. tiles coming from an array of samples loaded in memory, or
3. tiles coming from an array of sample coming from a single file).
   That's why we'd probably need both a sample_id and a file_id (or a unified hash) to make sure every tile is uniquely assigned to an image.
   Moreover, we also need to make sure that these IDs are "uniquely sortable", so that images returned by the stitching function are in the same order of the images provided, e.g., for evaluation (this would avoid troubles in computation of metrics and so on).

[jdeschamps]

Do you have an implementation of the solution or just a quick fix? Just wondering whether it is worth a PR before we refactor all the datasets.