Consider getting rid of RC4 / ARC4

[cfcs]

I think it would make sense to get rid of the (A)RC4 implementation that is currently the only exposed Cipher_stream.S.

1. If we don't want to remove it, perhaps we should add a deprecation warning to at least make it visible to people that their software is using broken crypto, or move it to a Broken_crypto submodule or similar. It would also make sense to not have the only stream-cipher exposed be a broken one, ie there should be a usable alternative if we want to carry this API at all. Chacha20, Salsa20, or some of the SPECK family, for instance.

2. see @pqwy 's comment here about the implementation being "homework-grade" and RC4 being "considered harmful": https://github.com/mirleft/ocaml-nocrypto/issues/4#issuecomment-208087391

3. The wikipedia article has a lot of references as to why RC4 shouldn't be used.

4. Notably: IETF forbade it in TLS in RFC 7465

[avsm]

I'd be fine deprecating it. One of the irritations with removing it is that it lingers in some protocols we may have to interop with (WEP, WPA default, pdf encryption). For the more persistent formats like pdf, it will probably be around for some years due to existing files.

[cfcs]

@avsm Yes, hence my point 1) about moving it. Same can be said for DES, IDEA, Camellia, GOST, 3DES, MD5, MD4, MD2, and so on. It's useful for historical reasons, but ideally there'd be a clear separation between obviously broken things and what we consider reasonable for practical modern use.

EDIT: For instance I personally still have use for SSL 3.0 since it's the latest version of SSL supported by my OpenVMS machine, but I think it's completely reasonable that I have to jump through some hoops to get this accepted in a modern browser. :)