Make size_t its own type

[Walter Bright]

I share your pain working with diverse C compilers with their diverse ideas of 
what warnings should be emitted, and how they often contradict each other. 
Things get worse when using C code checkers.

This is why I've tried hard to not even have warnings in D.

Anyhow,

I have a lot of experience moving code from 16 to 32 to 64 bits, and the effects 
of size_t. The error messages come from misusing size_t. D does it better by 
flagging implicit casts that lose bits (casting from 64 bit size_t to 32 bit). 
My problems porting D code 32<=>64 have vanished because of this. There might be 
an error now and then compiling 64 bit code to 32 bit code, but at least the 
error happens at compile time.

The biggest problem I had with size_t is printf format string mismatches. When 
the format string checker was added, that problem thankfully disappeared.

I understand you want to flag the error even when compiling 64 bit code. The 
problems with defining a new type:

1. break any code that sets its own size_t type

2. break any code that relies on the name mangling

3. added complexity to function overloading

4. new overloading rules, not at all simple

5. existing code that has cases for each type will miss the new size_t

Regarding dchar: That came about at the creation of D. I thought at the time 
that dchar would be how people process text. That, of course, never happened, 
and dchar doesn't have much of a role these days.

You can still create a unique type for size_t, as size_t is not set by the 
compiler, but by druntime.

```
struct size_t {
     ...
}
```
and give it the desired behavior. Perhaps that can help with determining how 
useful it would be. D has had success with deprecating the builtin 
imaginary/complex floating point types and replacing them with structs. I have 
also implemented the `struct halffloat` which provides support for 16 bit 
floating point.