Avoid gnulib getline module.

Avoid gnulib getline module.

Outside of the test suite, we only use getline in one location.  Instead
of pulling in gnulib's replacement implementation and its dependencies,
adjust the do_getline funciton to directly incorporate a pure standard
C fallback.

Since there is also some getline use in the test suite, rearrange the
code a bit so that we can also include do_getline in the tests.

The gnulib configure tests for getline seem to be complete overkill.
According to the gnulib documentation, the portability problems which
gnulib solves are:

 (a) The function is missing on some platforms.
 (b) On FreeBSD 8, getline crashes if passed a null pointer and a
     nonzero size.
 (c) On AIX 7.1, there is no declaration in <stdio.h>.
 (d) Some unspecified system has an unrelated getline function
     which may erroneously satisfy link tests.

It is unclear to me that gnulib actually solves (c) in a reasonable way.
On AIX 7.2, getline is properly declared in <stdio.h> but gnulib rejects
it anyway and substitutes its own reimplementation as if it didn't exist
at all.  Presumably the exact same thing happens on AIX 7.1.

So I don't see any reason for the annoying runtime tests just to check
if we have issue (d) and linked an irrelevant getline.  Although it's
hard to know for sure since I don't know what system has this problem,
surely it is good enough to just check that getline is properly declared
in <stdio.h> and that we can successfully link against it.  This check
can be implemented with just one single AC_LINK_IFELSE invocation.

I feel that issue (b) is much more sensible to work around in the source
code (by initializing the size to zero), that way we don't need to probe
for it at all or reject this implementation.

Funnily enough there is an unmentioned bug in the AIX 7.2 getline which
is not the reason it gets rejected by gnulib: passing a buffer size of
exactly one byte causes it to return 0 immediately instead of actually
reading input and enlarging the buffer.  Work around that problem too
in the rendertest application (the only place that can hit it).