Fix missing AC_PROG_SED on older Autoconfs

For pre-2.59b Autoconfs, AC_PROG_SED is not available [1]; on such
systems, avoid calling AC_PROG_SED, while providing a sensible SED.

This aids backporting to Autoconf 2.59.

[1] http://lists.gnu.org/archive/html/autotools-announce/2004-08/msg00002.html
Backport libevent to vanilla Autoconf 2.59 (as used in RHEL5)

This is a backport of ad03952.
Merge remote-tracking branch 'origin/patches-2.0'
a program to print out the error strings for winsock errors
use FormatMessage for winsock errors

as discussed here:
http://archives.seul.org/libevent/users/Feb-2013/msg00004.html
make sure caching works, and we don't leak memory
use hashtable instead of linked list to cache winsock errors

as discussed here:
https://github.com/libevent/libevent/pull/41#issuecomment-13611817
test filling up the hash table a bit
Merge pull request #41 from ppelleti/winsock-errs

FormatMessage for winsock errors
Add sample/https-client.c, an example of stacking evhttp as a client on top of bufferevent_ssl.

Signed-off-by: Catalin Patulea <catalinp@google.com>
use ${OPENSSL_LIBS} instead of -lssl -lcrypto

This made the difference between segfaulting and not segfaulting for
me when I run https-client, when I've built libevent using an OpenSSL
in a non-standard location.

In the same spirit as 1d9d5110a4aebf5833f6fd78bd0252affde0f4d0 and
d70af27d0152d0a87a25127faf215604beb8ffe0.
https-client was putting newlines at 256-byte boundaries

presumably this was meant to put a ">" before every line, but that
isn't what it does, since evbuffer_remove is simply returning
fixed-size chunks.  So, when retrieving a document of more than 256
bytes (e. g. any nontrivial document), we got "> " and newlines thrown
in at very arbitrary places.
better handling of OpenSSL errors
use Debian's default root certificate location

as suggested here:
http://archives.seul.org/libevent/users/Feb-2013/msg00034.html

although curl's acinclude.m4 reveals many other possibilities:

dnl /etc/ssl/certs/ca-certificates.crt Debian systems
dnl /etc/pki/tls/certs/ca-bundle.crt Redhat and Mandriva
dnl /usr/share/ssl/certs/ca-bundle.crt old(er) Redhat
dnl /usr/local/share/certs/ca-root.crt FreeBSD
dnl /etc/ssl/cert.pem OpenBSD
dnl /etc/ssl/certs/ (ca path) SUSE

And none of these cover Windows :(
use iSECPartners code to validate hostname in certificate

The problem is that if you go to a website whose certificate does not
match its hostname, it should fail.  Try this in a web browser for
https://www.kegel.com/ for example.  Your web browser will say the
certificate is for *.pair.com, not for www.kegel.com, and won't let
you visit it without clicking through a bunch of scary warnings.

However, prior to this commit, https-client was happy to fetch
https://www.kegel.com/ without complaining.  That is bad.  Now, with
this commit, it will properly complain, which is good:

pelletier@chives:~/src/libevent/sample$ ./https-client https://www.kegel.com/
Got 'MatchNotFound' for hostname 'www.kegel.com' and certificate:
/C=US/postalCode=15203/ST=Pennsylvania/L=Pittsburgh/street=Suite 210/street=2403 Sidney Street/O=pair Networks, Inc./OU=Provided by pair Networks, Inc./OU=PairWildcardSSL $250,000/CN=*.pair.com
some request failed - no idea which one though!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ppelletier@chives:~/src/libevent/sample$

It will still succeed for sites with an exactly-matching certificate,
such as https://github.com/ and that is also good!

However, the problem is that the iSECPartners code doesn't handle
wildcards, which means we reject https://ip.appspot.com/ even though
it is perfectly legitimate, because we don't understand the wildcard:

ppelletier@chives:~/src/libevent/sample$ ./https-client https://ip.appspot.com/
Got 'MatchNotFound' for hostname 'ip.appspot.com' and certificate:
/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com
some request failed - no idea which one though!
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
ppelletier@chives:~/src/libevent/sample$

So, we need to fix this.  In other words, "to be continued..."
avoid sign mismatch warning in openssl_hostname_validation.c

sample/openssl_hostname_validation.c: In function 'matches_common_name':
sample/openssl_hostname_validation.c:80: warning: comparison between signed and unsigned integer expressions
sample/openssl_hostname_validation.c: In function 'matches_subject_alternative_name':
sample/openssl_hostname_validation.c:124: warning: comparison between signed and unsigned integer expressions
pull in wildcard matching code from cURL

Now, https-client accepts both:

https://ip.appspot.com/ (matching wildcard certificate)
https://github.com/     (matching non-wildcard certificate)

but still rejects

https://www.kegel.com/  (non-matching wildcard certificate)

which should match the behavior of these sites in a web browser.
uri decode: fix for warning "use of uninitialised value"

This patch add check in evhttp_decode_uri_internal() that next 2 symbols
are exists in array of chars for decoding, if don't have two next 2
symbols don't try to decode '%FF'
uri decode: changed the test for the existence of the next character

Fix for 64b6eceaba1a4

More info here
https://github.com/azat/libevent/commit/64b6eceaba1a40ab0b175fa9fd9329d3e978ce6e#commitcomment-2714685
Move prototype of evhttp_decode_uri_internal() to http-internal.h

Make it non static, that can be called from tests