[m-rev.] for review: replace some uses of 'arity'

[Julien Fischer]

On Thu, 17 Feb 2022, Zoltan Somogyi wrote:

> Replace some 'arity's with {pred_form,user}_arity.
> 
> This removes uncertainty in the affected places in the compiler,
> because unlike the 'arity' type, the pred_form_arity and user_arity
> types specify *which definition* of arity they represent.
> 
> Whether I replaced a use of arity with pred_form_arity or user_arity
> depended on whether I believed the original arity to have been intended to be
> - a pred_form_arity without the wrapper, or
> - a user_arity without the wrapper.
> The reason for the size of this diff is that when I replaced one use of
> arity with pred_form_arity or user_arity, I often could not be sure about
> the right way to propagate this change to the rest of the affected code
> without making similar replacements elsewhere, and seeing whether
> that worked. This diff is in effect the "smallest fixpoint" of this process.
> 
> In places where the pred form arity of predicate or function
> is inherent in a list which has one element for each argument
> (the element may be a term, a type, a mode, etc), do not take
> a separate arity argument as well, since (a) it is not needed, and
> (b) it is a potential source of inconsistencies. The only downside
> is that we may need to take the length of a list in both the caller
> and the callee, but this cost is negligible.

That's fine.

Julien.