RFC: Alternate Stitcher framework

[vinamarora8]

This PR introduces an alternate stitcher framework. This framework has two main goals:

1. Separating stitching logic/API from metric computation and logging.
2. Introduce a good API for stitching. Motivation: If stitching is made low-effort and intuitive, we can expect developers to take care of stitching+metric computation by themselves. This means we don't have to design and maintain a collection of stitcher/metric-computation frameworks.

The Stitcher API:

stitcher = Stitcher()
stitcher.update(timestamps1, preds1, targets1)
stitcher.update(timestamps2, preds2, targets2)
stitcher.update(timestamps3, preds3, targets3)
stitched_preds, stitched_target = stitcher.compute()
stitcher.reset()

The training-script developer has to use these Stitcher objects inside the train_wrappers. As an example, look at POYO's training script.

We can also consider introducing a StitchedMetric class, with the following API:

stitcher = StitchedMetric(torchmetrics.R2Score())
stitcher.update(timestamps1, preds1, targets1)
stitcher.update(timestamps2, preds2, targets2)
stitcher.update(timestamps3, preds3, targets3)
metric = stitcher.compute()

My testing has been on POYO-MP scale, and I observe that the modification that this PR brings is zero-cost. i.e., the validation epoch time does not change.