BUG/MAJOR: fix haproxy crash when using server tracking instead of checks

Igor at owind reported a very recent bug (just present in latest snapshot).
Commit "4a741432 MEDIUM: Paramatise functions over the check of a server"
causes up/down to die with tracked servers due to a typo.

The following call in set_server_down causes the server to put itself
down recurseively because "check" is the current server's check, so once
fed to the function again, it will pass through the exact same path (note
we have the exact symmetry in set_server_up) :

	for (srv = s->tracknext; srv; srv = srv->tracknext)
		if (!(srv->state & SRV_MAINTAIN))
			/* Only notify tracking servers that are not already in maintenance. */
			set_server_down(check);

Instead we should stop the tracking server being visited in the loop :

	for (srv = s->tracknext; srv; srv = srv->tracknext)
		if (!(srv->state & SRV_MAINTAIN))
			/* Only notify tracking servers that are not already in maintenance. */
			set_server_down(&srv->check);

But that's not exactly enough because srv->check->server is only set when
checks are enabled, so ->server is NULL for tracking servers, still causing a
crash upon first iteration. The fix is easy and consists in always initializing
check->server when creating a new server, which is what was already done a few
patches later by 69d29f9 (MEDIUM: cfgparse: Factor out check initialisation).

With the fix above alone on top of current version or snapshot 20131122, the
problem disappears.

Thanks to Igor for testing and reporting the issue.
BUG/MAJOR: check: fix haproxy crash during soft-stop/soft-start

This is the continuation of previous fix bc16cd8 "BUG/MAJOR: fix haproxy
crash when using server tracking instead of checks", the soft-stop/start
states were not addressed by this fix.
BUG/MINOR: stats: do not report "via" on tracking servers in maintenance

When a server tracks another one, its state on the stats page always reports
"via xx/yy". That's convenient to know what server to act on to change the
state. But it is also possible to force the tracking server itself into
maintenance mode and in this case we should not report "via xx/yy" because
the tracked server can't do anything to change the server's state, which
is confusing. In practice there is nothing wrong in leaving it as-is,
except that it's highly misleading when looking at the stats page.

Note that we only change the HTML output, not the CSV one. The states are
already different : "MAINT" vs "MAINT(via)" and we expect anyone coding a
monitoring system based on the CSV output to know the differences between
all possible states.
BUG/MEDIUM: sample: The function v4tov6 cannot support input and output overlap

This patch permits to use v4tov6 with the same input and output buffer. It
might have impacted the format of IPv4 addresses stored into IPv6 tables.
BUG/MINOR: arg: fix error reporting for add-header/set-header sample fetch arguments

The 'add-header %[samples]' parsing errors associated to http-request
and http-response are displayed with the wrong keyword.

Configuration entry:

   http-request set-header mon-header %[res.hdr(user-agent)]

Original error message:

   [WARNING] 323/150920 (16559) : parsing [haproxy.conf:36] : 'log-format' : sample fetch <res.hdr ...

After commit error message:

   [WARNING] 323/150929 (16580) : parsing [haproxy.conf:36] : 'http-request' : sample fetch <res.hdr ...