[ refactor ] fix #2865

[jamesmckinna]

This is one approach to #2865 but having committed this, I see a couple of possible pain points:

• what exactly should the CHANGELOG be, given the somewhat underspecified entries from Add various relations over non-empty lists #2862 , and that this is strictly speaking 'just' a revision of an existing v2.4 set of changes?
• what exactly should the names be? (REVISED; see most recent commits; I'd like to re-use the name satisfiable, but I guess that might be breaking... sigh))

If nothing else, it serves to make concrete the discussion of the issue #2865 and any candidate solution. I've updated the issue with my latest thoughts on the matter, so maybe it's worth making this DRAFT until that discussion shakes out?

[JacquesCarette]

I'm not against this change (and would be willing to change my comment to an approve), but I do find Any.any⇒satisfiable quite redundant. (I'm fine with the change wrt + and - superscripts, that is more coherent.)

I'm not sure of the balance between having names spelled out in full what the function does and using more contextual information (it's in the Any module!) wrt saying what the function does.

[jamesmckinna]

Thanks @JacquesCarette I'll update the PR in line with my new thinking as discussed on #2865 ... Aaargh! re-using a name, but only one introduced by #2862 so it's OK to:

• rename satisfied to satisfiable in Data.List.Relation.Unary.Any
• rename correspondingly in Data.List.NonEmpty.Relation.Unary.Any, and as that was introduced only under Add various relations over non-empty lists #2862 for v2.4, that seems OK!?
• double-down on my reasoning on the original issue, and introduce in Data.List.Relation.Unary.Any
  • satisfiable⁺ : Satisfiable P → Satisfiable (Any P)
  • satisfiable⁻ : Satisfiable (Any P) → Satisfiable P

Arguably the last two additions are... potentially confusing, but I think they are consistent with our style-guide policies.