Send "fake '*' key" in "MODE -k" replies

According to RFC 2812 3.2.3 "Channel mode message" and the examples
there, it looks like clients should use "MODE -k <key>" to unset channel
keys; and that's how other servers and services behave and do expect it.

(But please note that this is NOT the case for "MODE -l"!)

In the end, it doesn't make sense to specify a key when UNsetting it at
all, and different services behave diffrently when clients do not send
the currently set key to unset it - some ignore such calls, for example!

But this implementation is quite relaxed, it accepts any key when
unsetting channel mode "k" and even accepts no key at all. But the reply
will always include an "*" character for every "-k" parameter.
Test suite: explicitely enable glibc memory checking
Client_SetHostname(): Don't use strlen() to test for value
platformtest.sh: New option "-x", don't renegerate build system
platformtest.sh: Show only up to 10 bytes of version information
platformtest.sh: Allow using separate source and build trees

Now you can call platformtest.sh using its complete path name from an
other directory which is then used for building.

See <http://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html>

Please not that the build system itself is still (re-)genrated in the
original source tree. This can be avoided by passing the "-x" switch to
the platformtest.sh script.
Remove "range matching" functionality

Don't support "range marching" in our pattern matching code using
the "[...]" syntax, because [ and ] are valid characters in nick
names and one has to quote them currently using the "\" character,
which is quite unexpected. For example:

  Nick "te[st" => "MODE #channel +b te\[st"

And remove quoting altogether, too, because "*" and "?" don't need
to be quoted because these characters are not allowed in IRC masks,
nicks, and hostnames.

Reported by "hifi" (Toni Spets) on IRC, thanks!
Add libwrap at the end of the configure run

If libwrap becomes added earlier, other tests may fail because of not all
external variables required by libwrap are available when linking: for
example allow_severity and deny_severity.

This patch adds generic support for the LDFLAGS_END and LIBS_END variables
(CFLAGS_END has been implemented already).

Problem spotted on OpenBSD.
Fix configure script and "make check" for TCP Wrappers

Add missing #include's and static variables.

Problem spotted on OpenBSD.
Use $(MKDIR_P) instead of $(mkinstalldirs) in Makefile's

And test for "mkdir -p" using AC_PROG_MKDIR_P in "configure".
Merge branch 'no-range-matching' of git://arthur.barton.de/ngircd-alex

* 'no-range-matching' of git://arthur.barton.de/ngircd-alex:
  Remove "range matching" functionality
ngircd.conf.5: Update manual page
Show account name in WHOIS

This uses the same numeric as Charybdis and ircu families.
Merge pull request #5 from grawity/accountname-whois

Show account name in WHOIS
configure: Only link "contrib/Debian" if it exists

This isn't the case on "VPATH builds", for example.
Return ISUPPORT(005) numerics on "VERSION"

This is how ircd-seven, Charybdis, Hybrid, and InspIRCd behave,
for example.
Use correct sender as target for ISUPPORT replies on "VERSION"

This fixes commit 2e168c78 ("Return ISUPPORT(005) numerics on
'VERSION'") and make sure, that the 005 numerics are correctly
routed back to the sender.
Correctly use cloaked IRC masks on "INVITE nickname"

The cloaked IRC mask of a user is his visible mask, so the daemon has
to use it for generating the "one time" entries for the invite list of
the given channel.

Without this patch, ngIRCd records the real IRC mask which will never
match while the target client is "+x", and even worse, will disclose
the real mask on "MODE #channel +I" commands :-/

Bug reported by Cahata on #ngircd, thanks!
Streamline punctuation of log messages

See commit d38d153f for details.
IRC_INVITE(): Code cleanup