Pin to libcspice.so and not a specific version

[jlaura]

ISIS version(s) affected: 6.0.0+

Description
Related to #5080, we pin to libcspice.so.66, we should pin to libcspice.so or to the libcspice.so.67 (the current newest version).

How to reproduce

Possible Solution
Update the build recipe and the environment.yml.

Additional context
@AndrewAnnex has helped us out by releasing with a symlink from libcspice.so.67 to libcspice.so.66 (that we pin to). We need to update our builds so we do not have this faux version dependency (v66 is actually v67).

[AndrewAnnex]

possibly related to this issue, I am currently struggling with some github actions that keep pulling in the older build (h166bdaf_3) rather than the one with the fix (h166bdaf_4), and even fail to resolve h166bdaf_4 when specified in separate install commands or in environment yaml files (although, weirdly this works on a local machine just fine).

I suspect this has something to do with the dependency pins in ISIS that don't play nicely with conda-forge, but have little proof. I see other dependencies like jama and tnt that were added to the conda-forge month ago as still passed-over for those from the usgs channel.