[iterator.concept.winc] Refactor definition of "integer-like type"

[Quuxplusone]

• "I models integral<I>" is not how we say it: the <I> shouldn't be there.
• The concept integral is modeled only by integral types. Cut out the middleman.
• Make the sentence structure less hypothetical; use "collectively called" as we usually do.
• Clearly specify that cv bool is not integer-like, rather than leaving it out of the premise.

[jensmaurer]

Where is this "bool" exclusion coming from? It's not in the original text for unsigned-integer-like.

[Quuxplusone]

The original text is

An integer-like type I is unsigned-integer-like if it models unsigned_integral<I> or if it is an unsigned-integer-class type.

Now, is bool an unsigned-integer-like type? Arguably the reader can't use the original sentence to say one way or the other, since the original sentence tells us anything at all only for "an integer-like type," which bool isn't.

But the intent, I think, is that the unsigned-integer-like types should be a strict subset of the integer-like types.

Suppose the new text was:

Unsigned-integer-class types, and types other than cv bool that model unsigned_integral, are collectively called unsigned-integer-like types.

Then bool (which models unsigned_integral) would be considered unsigned-integer-like but not integer-like. I'm sure we don't intend that.

[Quuxplusone]

Alternatively, how about this? (Signed-integer-class types and unsigned-integer-class types are collectively known as integer-class types: [iterator.concept.winc]/3.)

Signed-integer-class types and types that model \tcode{\libconcept{signed_integral}}
are collectively called \defnadjx{signed-integer-like}{types}{type}.
Unsigned-integer-class types, and types other than \cv{}~\tcode{bool} that model \tcode{\libconcept{unsigned_integral}},
are collectively called \defnadjx{unsigned-integer-like}{types}{type}.
Signed-integer-like types and unsigned-integer-like types
are collectively called \defnadjx{integer-like}{types}{type}.

This puts the "except bool" exception in just one place instead of two, and makes it very clear that integer-like types are precisely partitioned into signed and unsigned just like integer-class types are partitioned into signed and unsigned and integral types are partitioned into signed and unsigned.