Per discussion at #565 (review).

Generally I believe that there should be a bigger focus on readability of the concepts. Currently a lot of the more complex concepts are really hard to grog due to unfortunate formatting. I believe that we would gain a lot by spending a few lines more to improve the general readability.

I agree. I've been trying to format the constraint-expressions in concepts as clang-format would - with the expectation that it will reduce churn someday when clang-format learns to understand concepts and requires-clauses - but I've started cheating here and there when it helps readability. We should simply go all in and format them one-term-per-line (except for very simple cases) as in the Ranges TS.

I'll update the concept definitions that this PR touches, and file an issue to make a general audit.

We should audit all concept definitions for readability. Some guidelines:

• The first line of the definition may contain multiple terms if they aren't too complex visually.
• Try not to split disjunctions across multiple lines if possible (we prefer Conjunctive Normal Form)
• Continuation lines should generally have a single term, although there are exceptional cases where multiple terms can better convey structure. For example:

  template <class _Ty>
  concept copy_constructible = move_constructible<_Ty>
      && constructible_from<_Ty, _Ty&>       && convertible_to<_Ty&, _Ty>
      && constructible_from<_Ty, const _Ty&> && convertible_to<const _Ty&, _Ty>
      && constructible_from<_Ty, const _Ty>  && convertible_to<const _Ty, _Ty>;

• Terms with many and/or complex arguments can be split across multiple lines:

  template <class _Fn, class _It>
  concept indirectly_unary_invocable = indirectly_readable<_It>
      // ...snip...
      && common_reference_with<
          invoke_result_t<_Fn&, iter_value_t<_It>&>,
          invoke_result_t<_Fn&, iter_reference_t<_It>>>;