Remove unused leftover artificial key _reflns_shell.d_res_limits

[jamesrhester]

_reflns_shell.d_res_limits is constructed from the upper and lower limits of a resolution shell. It was originally created to be a single key data name for this category, but is no longer used for that and is unlikely to have been used in data files. Will be backported to release candidate.

[vaitkus]

The data name has most likely not been used in any data files, but it is referenced in one of the recently published
ITG chapters [1]:

For example, according to the DDLm version of the coreCIF dictionary, the resolution value
extrema can be recorded using either a two-element list data item (_reflns_shell.d_res_limits)
or a pair of single-valued data items (_reflns_shell.d_res_low, _reflns_shell.d_res_high).

Not sure if this is a sufficient reason to not remove the item. I will also ask the editors if the chapter
itself could be edited/updated given that it most likely has only been published in the digital format.

[1] https://it.iucr.org/Gb/ch5o1v0001/

[jamesrhester]

Hmm, unfortunate. If the chapter cannot be easily updated, then we should keep this data name and I will reduce the PR to simply making sure it is not a Key. Let's see what @nautolycus thinks.

[nautolycus]

I think on balance I would prefer to retain the status quo ante.

• (1) The item has already been published in an official dictionary release (https://www.iucr.org/__data/iucr/cif/dictionaries/cif_core_3.2.0.dic), and I am reluctant to remove anything that has been released.
• (2) Although `only in the digital format', Chapter 5.1 has been formally published. Revisions might be considered to correct errors of fact, but the discussion is both correct as of the time of writing, and also has some didactic merit.
• (3) I'm OK with removing the descriptive reference `This is the category key.' The formal (machine-actionable) identification of the category key is in the category definition:

    loop_
      _category_key.name
         '_reflns_shell.d_res_low'
         '_reflns_shell.d_res_high'

There are other instances where a category key consists formally of a number of discrete items, for which there is also a corresponding compound data name. @jamesrhester and I have been discussing offline the example of exptl_crystal_face.index_h, *_k and *_l and _exptl_crystal_face.hkl. If the individual h, k, l indices are mandatory (because they form the category key) in a tabulation, in what circumstances, I asked, would _exptl_crystal_face.hkl ever be used? James suggested it has a use (because it expresses a vector quantity) within dREL methods. So perhaps this discussion can be taken up in the core chapter, and a reference to the discussion in Chapter 5.1 could emphasise that such equivalences may only be beneficial in internal processing. I think the existing 5.1 text does tend somewhat to discourage the practice it discusses anyway.

[jamesrhester]

Closing in light of reasonable objections raised above.