Globally replace ambiguous use of "constraints"

[hubert-reinterpretcast]

P0734R0 presumably defines "constraint" as a term of art.
The Working Draft prior to integrating P0734R0 already uses "constraint" with another meaning.

The use of "satisfied" is less of an issue since P0734R0 would only define it in relation to satisfying a constraint.

[jensmaurer]

We use "constraint" in its English meaning quite a bit. Maybe use "template-constraint" for the P0734R0 meaning, similar to our artificial phrases odr-used and injected-class-name?

[hubert-reinterpretcast]

"template-constraint" would work. Not sure how much discussion such a change would generate though.

[jensmaurer]

Editorial meeting consensus: We have constraints on non-templates. "template-constraint" is probably not going to work. Try to use bare "constraint" only within 17.4 temp.constr, everywhere else we should ensure we never use bare "constraints", but "associated constraints" or similar.

[jensmaurer]

A quick search shows that we use "constraint" all over the place to talk about restrictions established by the surrounding specification text, totally unrelated to concept-style constraints. We need a new plan.

[zygoloid]

Approach: replace "constraints" with "associated constraints" everywhere that is correct, then look again at what instances of "constraints" remain that refer to the Concepts notion of constraints and make more decisions.

[tkoeppe]

Is there still work pending for this issue?

[jensmaurer]

We seem to use "associated constraint" or "atomic constraint" or "constraint-expression" pretty universally where we mean it. Please open a new issue with specific references if you find violations somewhere.