[Bug libstdc++/89477] Incorrect CTAD deduction guides for set and multiset

[arthur.j.odwyer at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89477

--- Comment #4 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
libstdc++ passes all my test cases now except this one:
```
// https://godbolt.org/z/kvh9Ih
#include <set>
std::set<int> s;
std::set t(s, std::allocator<long>());
```

The issue is that we humans can logically deduce t's Allocator parameter as
"the same as s's Allocator parameter", but due to an implementation detail, the
compiler is also trying to deduce t's Allocator parameter as
std::allocator<long>, and so it deduces conflicting types and fails deduction.

This test case could be made to work if you changed
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_set.h#L124
from
    typedef _Alloc   allocator_type;
to
    typedef typename __identity<_Alloc>::type   allocator_type;
or whatever libstdc++'s equivalent of __identity is.

MSVC's `set` already effectively does this, by inheriting its `allocator_type`
typedef from a base class. I don't know whether the paper standard has a
definite interpretation one way or the other; it might be open to
interpretation, or it might even say that MSVC is wrong in this case.
(Logically, I think MSVC *should* be right.)

Perhaps a new bugzilla issue should be opened for this one.