[RFC] Ensure well-defined alloc behaviour.

clang defect report [1] caught this potential bug in memory.c, line 112:

> Call to 'calloc' has an allocation size of 0 bytes

calloc(0,x) or (x,0) and malloc(0) may return a NULL or non-NULL pointer
[2] on some implementations. Set the size and/or count to at least one
before calling an alloc() function to avoid undefined behaviour.

[1] defect report:
http://ruiabreu.org/neovim-analysis/report-oLRUxF.html#Path4

[2] http://man.he.net/man3/calloc

I'm certain that no code using `xcalloc()` right now is broken. I experimentally found that gcc will zero-fill at least 24 bytes of space, even on `calloc(0,0)`, but I hope nothing actually relies on that behaviour.

```c
#include <stdlib.h>
#include <stdio.h>

int main() {
    char* p = calloc(0,0); // OOPS!

    if( p == NULL ) return 1;

    size_t i = 0;
    for( ; p[i] == 0; i++ )
        printf("char @ %zu = %i\n", (size_t)p + i, (int)p[i]);
    printf("char @ %zu = %i\n", (size_t)p, (int)p[i]);

    free(p);
    return 0;
}
```
Tested with:
```bash
$ gcc alloc.c
$ ./a.out | wc --lines
25
```

static analyser: #167 
It's a false positive. If malloc/calloc isn't happy with 0 size (i.e.
return NULL) I try size=1.

If some client code calls xmalloc with size 0 it shouldn't read the
allocated memory. It is bug and there's nothing reliable you can do inside
x*alloc to solve that. Trying to allocate 1 byte is a way to guarantee that
x*alloc will never return null. I only resort to that if the system
allocation function can't handle that by itself.

I guess the same rationale works for the malloc implementation. Client code
may allocate 0 bytes and not even read the allocated memory, but may test
if it's NULL and mistakenly handle that as an OOM. This is not good.

The issue here is that the analyzer doesn't know malloc/calloc is being
used to implement allocation functions. To work well, the analyzer should
analyze calls to x*alloc functions looking for possible size=0. "user
defined allocation function analysis" may be something worth asking for in
their issue tracker.

__
Felipe O. Carvalho (philix)
http://felipe.rs