uintptr_t detection incompatible with "using namespace std"

[BillyDonahue]

Break introduced by b23c863 Detect presence of uintptr_t

The change injects fmt::internal into namespace std with a using directive.
fmt::internal has its own uintptr_t, which is a typedef to a struct.
This simple file now can't build:

#include <stdint.h>
#include <fmt/format.h>
using namespace std;
uintptr_t x;

https://gcc.godbolt.org/z/d0q6LP

<source>:5:1: error: reference to 'uintptr_t' is ambiguous
uintptr_t x;
^
/usr/include/stdint.h:100:27: note: candidate found by name lookup is 'uintptr_t'
typedef unsigned long int       uintptr_t;
                                ^
/opt/compiler-explorer/libs/fmt/trunk/include/fmt/format.h:247:8: note: candidate found by name lookup is 'fmt::v5::internal::uintptr::uintptr_t'
struct uintptr_t {
       ^
1 error generated.
Compiler returned: 1

The uintptr_t detection is making some compromises with C++ conformance in order to avoid having an explicit autoconf-style #define.

(The specialization of numeric_limits looks like a C++ language violation too, but it's not my immediate problem.)

I'd like to be able to overrride all the shenanigans with a #define or something, since I know I have uintptr_t.

[vitaut]

Yeah, injecting into the std namespace was a terrible idea. Fixed in e5422db.