Implement LWG-3660 for iterator_traits<common_iterator>::pointer

[CaseyCarter]

LWG-3660 "iterator_traits<common_iterator>::pointer should conform to [iterator.traits]" requires a tweak to iterator_traits so it always agrees with operator->().

Also removes comments for LWG-3601 and LWG-3616 which have been voted into the Standard, see #2527.

[StephanTLavavej]

I've updated this PR's title (and #2548) to include a short explanation of what the LWG issue is about. (They don't need to copy the issue's name exactly, just have a quick summary.) This makes it easier to read the Code Reviews project (so we don't have to memorize what each LWG issue number means) and will make it easier to read the commit history when this is eventually merged.

[StephanTLavavej]

Mega-nitpick, not worth resetting testing, no change requested: The empty comment // (to force wrapping) is unnecessary in a clang-format off region.

[CaseyCarter]

Argh.

[frederick-vs-ja]

Is it intended that common_iterator::operator-> sometimes returns the iterator by reference?
The Range-v3 and Ranges TS versions of common_iterator::operator-> always return by value. But since respecifying common_iterator with variant, it has been made returning by reference in some circumstance.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo. Requesting or pushing changes is totally fine, but please notify me if that happens.

[CaseyCarter]

Is it intended that common_iterator::operator-> sometimes returns the iterator by reference? The Range-v3 and Ranges TS versions of common_iterator::operator-> always return by value. But since respecifying common_iterator with variant, it has been made returning by reference in some circumstance.

It's certainly what the spec requires, although looking at it today I'm not sure why. Maybe I wanted to avoid unnecessary iterator copies? Maybe I thought doing so would make it easier to support move-only iterators?

[StephanTLavavej]

Thanks for fixing this iterator_traits machinery! 🛠️ 🎉 😻