features.loc[feature_name] not working consistently

[drvdputt]

We build an index for a Features table, so that rows can be accessed by the feature name. In certain contexts, this index is no longer available, so .loc will throw ValueError: Can only use TableLoc for a table with indices.

Findings so far

• Root cause: applying deepcopy() to a Features table, does not preserve the index. (features.indices is empty after copying)
• Related: in PAHFITcube, I get a similar issue when using multiprocessing. This has something to do with the pickling an unpickling of the Features table, after which the indices are also not preserved.
• Strangely this does not happen in all of the tests. So far it seems that only the tests with astropy==6.1.0 show this behavior.

So it could be the astropy version (6.1.0 vs 6.0.1?), or the python version (behavior of deepcopy between 3.9 vs 3.10 vs 3.11?). The workaround, is to avoid the use of loc in the code, and just use the filter features['name'] == feature_name instead.
On the user end, things seem mostly fine, so we can still support .loc there.

[jdtsmith]

The user can edit/add/change priority for loc too so probably safer for us not to rely on it.