genhash: ensure CLRF{2} HTML body separator won't slip

Previously, the code (mistakenly) relied on \r\n\r\n sequence being read
from non-blocking socket in one go, which is not always the case.

This patch builds upon existing infrastructure to "minimize buffer using
no 2*CR/LF found yet" that was probably designed for what is completed
now -- keep up to 4 last bytes of the last read at the beginning of the
working buffer (as these might fit the separator or its part that would
be missed upon subsequent processing), append read data from the current
one and only then try to extract the beginning of HTML body start from
it.  This should guarantee we never miss this event.

Previously, it was possible as observed with, e.g., Python
SimpleHTTPServer.  In such case, the MD5SUM returned was that
of empty string: d41d8cd98f00b204e9800998ecf8427e.

In the wider context of the project, it can have some negative
consequences.  Even after this changeset is applied, it might still
be recommendable to recheck the hash against the output of, e.g.:

  curl -k ${URL} | md5sum

but only in case no redirections or similar fancy things are present.

Also added is an executable test;  demonstration of the issue and
the fix is as follows (dot denotes success, 10 errors encountered
lead to premature exit):

$ ./genhash-test.sh
> Test TESTFILE=genhash-test.sh with
> MD5SUM=0fcdd1e13b2eb119f2eadf73463d2169
> Using GENHASH=../bin/genhash
> Waiting for Python SimpleHTTPServer...
> Serving HTTP on 0.0.0.0 port 8000 ...
> Python SimpleHTTPServer started

BEFORE:

> d41d8cd98f00b204e9800998ecf8427e
> .
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
> ..
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
>
> d41d8cd98f00b204e9800998ecf8427e
>
> --- 10 ---

AFTER:

> .....................................................................
> .....................................................................
> .....................................................................
> .....................................................................
> .....................................................................
> .....................................................................
> .....................................................................
> .................
> --- 0 ---

As apparent, previously the success was random, now it should be
reliable.

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>