LWG-3519 Incomplete synopses for <random> classes

Discussion from the meta-issue #1965:

• @frederick-vs-ja

  • Only implemented for linear_congruential_engine and non-standard linear_congruential (subject to removal in vNext).
  • Note that operator!=s are no longer provided since C++20.
  • Although not required by the current working draft, IMO we should...
    • make operator!=s hidden friends too,
    • consistently make operator== and operator!= for param_types hidden friends, and remove operator!=s since C++20.

• @MattStephanson

  Regarding LWG-3519, I have a branch that does most of this, but I was waiting to see if maintainers would have any comments about the partial work in <random>: Fixes subtract_with_carry_engine io #2088 on subtract_with_carry_engine, particularly whether this should be applied to the tr1 classes. Also, does it need testing? I suppose that would take the form of a class that's convertible to one of the std types, which should now not be comparable to the std type. @StephanTLavavej, I see you self-assigned this 3 weeks ago, is it possible it slipped through the cracks?

• @StephanTLavavej

  @MattStephanson I haven't had a chance to review <random>: Fixes subtract_with_carry_engine io #2088 yet as the C++20 and C++23 PRs have taken priority - it is still on the list of things I intend to review though 😸 (The rate of incoming PRs has slightly exceeded our rate of reviewing them, which has led to an increasing backlog.)

  I tend to view the tr1 classes as implementation details, which we retain for ABI and to avoid breaking legacy code (although we have deprecated them). The argument against extending recent Standard changes to them, is that we would be extrapolating the changes and that gives us the chance to get things wrong, or destabilize legacy code. The argument for would be that it would make the header more consistent, instead of appearing half-updated. I'd probably avoid extrapolating changes to tr1 but if you wanted to, I wouldn't object as long as they didn't appear to be too disruptive.