Make `applyo` use constraints

[brandonwillard]

buildo (soon to be replaced by applyo) will actually apply a rator to its rands and unify the result with its third argument: i.e. buildo(add, (1, 1), q_lv) should unify q_lv with 3.

We need to use the new constraint system to make sure that, for example, add(1, 1) is computed and unified with q_lv once rator_lv and rands_lv are fully ground in a goal like buildo(rator_lv, rands_lv, q_lv).

[brandonwillard]

There are some ambiguities regarding when/how a term should be constructed by the aforementioned constraint, and that leads me to believe that an entirely different goal should be designated to this function, and that applyo should simply cons the operator + arguments (like it currently does on most occasions).

[majidaldo]

is this still relevant since there is applyo?

[brandonwillard]

is this still relevant since there is applyo?

Yes, applyo still doesn't use constraints and—as a result—isn't correct/complete.