This change adds the stitched RC4-MD5 code from upstream OpenSSL but
exposes it as an AEAD. It's not a normal AEAD (it's stateful thus
doesn't take an nonce) but forcing pre-AEAD cipher suites in the AEAD
interface is less painful than forcing AEADs into the EVP_CIPHER
interface. Over time, more and more cipher suites will be exposed as
TLS-specific AEADs and then ssl/ can drop support for EVP_CIPHER.

See original code from upstream:
https://github.com/openssl/openssl/blob/master/crypto/evp/e_rc4_hmac_md5.c

Change-Id: Ia9267b224747f02be6b934ea0b2b50e1f529fab9
Reviewed-on: https://boringssl-review.googlesource.com/1043
Reviewed-by: Adam Langley <agl@google.com>

Apart from the obvious little issues, this also works around a
(seeming) libtool/linker:

a.c defines a symbol:

int kFoo;

b.c uses it:

extern int kFoo;

int f() {
  return kFoo;
}

compile them:

$ gcc -c a.c
$ gcc -c b.c

and create a dummy main in order to run it, main.c:

int f();

int main() {
  return f();
}

this works as expected:

$ gcc main.c a.o b.o

but, if we make an archive:

$ ar q lib.a a.o b.o

and use that:

$ gcc main.c lib.a
Undefined symbols for architecture x86_64
  "_kFoo", referenced from:
    _f in lib.a(b.o)

(It doesn't matter what order the .o files are put into the .a)

Linux and Windows don't seem to have this problem.

nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1].
Basically the linker will merge multiple common symbol definitions together.

If ones makes a.c read:

int kFoo = 0;

Then one gets a type "D" symbol - a "data section symbol" and everything works
just fine.

This might actually be a libtool bug instead of an ld bug: Looking at `xxd
lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive
doesn't contain an entry for kFoo unless initialised.

Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427

Initial fork from f2d678e6e8 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)