qrintf issues with autotools

I'm not a fan of autotools, but can't work around using it in this case. I encountered several issues when integrating qrintf into our Varnish build:

Because qrintf.h is included very early in the compile process, a number of header files are pulled in before any chance of including config.h is allowed. This breaks packages that self-define C environment options like `_GNU_SOURCE` or `_XOPEN_SOURCE` or the like.

In my specific case, this was solved by hacking qrintf.h to include:

``` c
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
```

fixes the issue. I would submit a PR, but I'm sure that someone has an autotools build where the relevant guard is `_HAVE_CONFIG_H` and the file is also named differently.

I ran into a couple of other problems related to autohell:
1. When qrintf-gcc is specified as the `CC` to use for `configure`, a number of header feature tests break. (A `ffsl(3)` test failed in jemalloc, for a specific case.) I worked around this by specifying CC as an argument to make.
2. CFLAGS are not passed to qrintf-gcc. This requires one to set relevant build options a la `CC="qrintf-gcc -std=gnu99 -Werror -Wall" make`.

All of these things would be more easily resolved if it was easier / safer to include qrintf in projects built using these "tools". (In the meantime, I've worked around these issues, so this is not a high priority issue or anything. I'd be happy to submit patches if you have better ideas than the hacky ones I made.)

Start with qrintf.h and the qrintf-gcc entry point, then reproduce the autotools integration problems described in the issue. Check how config.h inclusion, configure's CC-based feature tests, and CFLAGS propagation currently behave. Done means these integration issues are resolved or their supported build configuration is clearly established.

Written by the indexing model from the issue text.