Removing weak_equality And strong_equality

[AdamBucior]

Description

Partial implementation of #64

Checklist

Be sure you've read README.md and understand the scope of this repo.

If you're unsure about a box, leave it unchecked. A maintainer will help you.

• Identifiers in product code changes are properly _Ugly as per
  https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
• The STL builds successfully and all tests have passed (must be manually
  verified by an STL maintainer before automated testing is enabled on GitHub,
  leave this unchecked for initial submission).
• These changes introduce no known ABI breaks (adding members, renaming
  members, adding virtual functions, changing whether a type is an aggregate
  or trivially copyable, etc.).
• These changes were written from scratch using only this repository,
  the C++ Working Draft (including any cited standards), other WG21 papers
  (excluding reference implementations outside of proposed standard wording),
  and LWG issues as reference material. If they were derived from a project
  that's already listed in NOTICE.txt, that's fine, but please mention it.
  If they were derived from any other project (including Boost and libc++,
  which are not yet listed in NOTICE.txt), you must mention it here,
  so we can determine whether the license is compatible and what else needs
  to be done.

[BillyONeal]

We need to ask compiler maintainers if they are prepared for such a change.

[StephanTLavavej]

Can we just run the tests and see if C1XX, Clang, etc. experience failures due to this removal?

[BillyONeal]

Can we just run the tests and see if C1XX, Clang, etc. experience failures due to this removal?

As long as that includes their tests, sure. But there are Core wording changes in that paper, and the Core features look for those names we remove here, so that seems unlikely...

[CaseyCarter]

Can we just run the tests and see if C1XX, Clang, etc. experience failures due to this removal?

Clang doesn't yet support <=> in a released compiler. I think C1XX will be ok with us making the change, but I've asked a compiler dev to confirm.

[CaseyCarter]

I'm told the compiler will crash and burn on any use of <=> if the library doesn't define all of the comparison category types the compiler believes to be valid. So we'll have to orchestrate this carefully. We're preparing an internal PR with compiler changes and these changes with some preprocessor guards to keep internal builds and external builds working until the changed compiler is released. Once that successfully merges, I'll port the preprocessor bits into this PR and we'll merge here as well.

Ideally this will happen in time for VS 16.5p2, and we'll be able to complete the removals once it's released.

[CaseyCarter]

Updated with changes from the integration with the compiler.

1. We decided to have the compiler predefine a macro (__cpp_impl_p1959r0) to indicate that it won't crash and burn if weak_equality and strong_equality aren't defined. This will go away (both here and in the compiler) in a future update.
2. STL noticed that we could make some other drive-by cleanups while we're here.

[StephanTLavavej]

Thanks for improving the spaceship implementation! This will ship in VS 2019 16.5 Preview 2 (it's actually the last STL feature change to be merged, so congratulations).