Add support for user provided confidence interval data

[flemingjf]

Provide functionality for confidence intervals to be contained within models. When building a slice, allow users to provide metrics representing upper or lower confidence intervals for that slice, which then are accessed when rescaling and calculating scores. Metric aggregation occurs separately for each of the lower CI, main value, and upper CI to provide up to 3 scores per sample for each slice. Slice score rescaling 0-1 will be done once on the entirety of the slice such that the largest sample score between the 3 slice scores is mapped to 1 and the smallest is mapped to 0, ensuring that CI scores and main scores can be directly compared in magnitude.

Example:
TxpSlice(txpValueNames = "metric1", txpLowerNames = "metric2", txpUpperNames = "metric3")

[flemingjf]

Based on meeting discussion between Jonathon Fleming and David Reif on May 30th, 2025:

- If providing CI to a slice, should a user have to provide both lower and upper CI?
CI scores should be optional to provide, and users should be allowed to provide just one of the two. Some datasets might have just one bound.

- Should lower CI, upper CI, and main slice be allowed to have differing numbers of metrics (n) in their makeup?
n should be allowed to be different for all 3. Notably discussed, if a user decides to merge slices to create a new model, and one slice has CI but the other doesn't, then this would create a situation where the number of metrics in the main slice is different than the number of metrics in the CI, but is a logical scenario that should be allowed. This differing n could cause some issues in comparison of unscaled slice scores for the main and CI slice due to ToxPi using the sum during aggregation. See issue #26 for resolving this.

- How should missing data be handled in CI slices during slice aggregation and slice rescaling?
For lower CI, missing data should be treated the same as previous slice scores without intervals. This means that if a sample has at least one non-NA value for the lower CI slice, NA values will be treated as 0 during aggregation. If the sample has only NA values for the lower CI slice, its slice score is treated as NA until slice rescaling has finished, after which it will be assigned 0.
For upper CI, missing data should not be treated the same (as 0), as this will deflate the upper CI making the results seem more confident. Instead, if a sample has at least one non-NA value for the upper CI slice, NA values will be treated as the largest value in the column after metric transformation for aggregation, ensuring the least confidence for missing data. If the sample has only NA values for the upper CI slice, its slice score is treated as NA until slice rescaling has finished, after which it will be assigned 1.
Imputing missing data this way will ensure that all samples can be ranked for their upper/lower CI in a conservative manner such that results don't show more confidence than they actually have

- How should upper/lower CI overall scores be calculated if only some slices have CI?
If a user provides upper/lower CI metrics for some slices but not others, the slices that have NULL for upper/lower CI will use the main slice score when computing the upper/lower CI overall ToxPi score. When plotting results, those slices will not plot the NULL CI at all, allowing plots in which some slices have CI while others do not, or some slices that might only have a lower or upper CI plotted. This could potentially use more discussion.

- How should this be described in comparison to the previous bootstrap CI from the toxpi GUI?
These two methods for CI are quite different, and thus should be interpreted differently. The user provided CI are CI on the metric level, ie how confident are we in our raw data collection prior to the ToxPi analysis. It is one analysis in which all 3 are rescaled 0-1 and compared together, allowing for direct visualization of the magnitude difference in confidence between the main score and the CI score independent of other samples. The comparison occurs at the unscaled slice score level. For example, if a sample had the highest main unscaled slice score (50), and the highest main upper CI slice score (100), the variability is directly reflected as scores of .5 and 1 respectively (assuming the lowest was 0).
The bootstrap CI in the GUI are based on the variability between metric rankings in a slice and less the difference in the actual scores for a sample, and it occurs post data collection. Analyses are done independently of each other, and the comparison occurs at the final scaled slice scores and rankings. For example if a sample had the highest main unscaled slice score of 50, and after bootstrapping again it had the highest unscaled score but of 100, both the main and upper CI scores would be 1, as they were the highest in each analysis. Thus it represents the change in overall ranking based on variability in metric rankings, but it does not represent the underlying confidence in the raw data. This difference could be fleshed out better, and how to denote these differences if bootstrapping functionality is provided in the r package should be discussed.