Can't find any matches in `find_gridpoints()` when running gridsearch with any PlotPrefs

[Jacob-Stevens-Haas]

The plot_prefs argument to gridsearch includes a GridLocator-type attribute (plot_match) that handles which points in the gridsearch are included in plotting and saved in the results for later analysis. GridLocator allows matching specific parameters for the gridpoints and/or the gridpoints that are found as argmaxes/argmins for certain metrics plot axis combinations.

However, sometimes indexes refer to results, sometimes to gridpoints of parameters. Each of the latter creates a result for each metric, thus the array of results have one additional dimension than the array of gridpoints. find_gridpoints is looking for param indexes, but it's looking in a pool of result indexes that match the metric/plot axis criteria. Since param indexes are shorter by one dimension, they never match and find_gridpoints() returns an empty list.

[Jacob-Stevens-Haas]

This can be solved in several ways: 1) if _marginalize_grid_views() doesn't add the metric index in _metric_pad() 2) find_gridpoints() doesn't look for exact matches (i.e. it strips the metric index in result indexes) 3) Make ResultIndex and ParamIndex explicit, along with conversion between the two.

Also relates to some other problems in how a find_gridsearch() works: if metric/plot axis criteria in one series says that param gridpoint (1, 4) is tentatively included, that param gridpoint could match parameter criteria in a different series, even if that (1, 4) was not the argmax/argmin in its own series relevant metric/plot axis array. This undifferentiability suggests that some total index might be useful. The challenge is that, because each series has non-conformant array sizes, a global index of tuple[int, ...] would have some weird cases: e.g. (1, 5) does not imply that (0, 5) is a valid index. I'm not sure whether to still go with tuple[int, ...] or perhaps add complexity as tuple[int, tuple[int, ...]].