Turns out it wasn't the plain CRC32 algorithm that should have
been used, whoops!

The implementation was adapted from pseudo code from
Thomas Cioppettini.

I've renamed the PROXY header building option value for
checksum from crc32 to crc32c and updated the documentation.
There is no support for plain crc32 checksums.

This is the function that should be called regardless of
TCP or TLS being used. The proper usage for this function is:

{ok, ProxyInfo} = ranch:recv_proxy_header(Ref, Timeout),
{ok, Socket} = ranch:handshake(Ref),
...

Ranch takes care of everything else under the hood. Transports
now need to have a Transport:recv_proxy_header/2 function. For
ranch_ssl the function gets the port from the sslsocket() record
and then calls ranch_tcp:recv_proxy_header/2 with it.

This means that two undocumented features are currently used for
this, but the interface is really nice so that's a sacrifice
worth doing. Also worth noting is that OTP 22 should have an
alternative for gen_tcp:unrecv/2 so the only real issue is about
the sslsocket() record at the moment.

The race condition occurs when the restart is faster than
the cleaning up. With this commit the restart will perform
the cleanup if it was not done beforehand.

This will avoid some unnecessary logs by default.
SASL can be enabled to log these events.

This uses the undocumented function gen_tcp:unrecv/2.

Tests have been added for both gen_tcp and ssl connections,
including sending data in the same first packet, at least
for gen_tcp (ssl tests may or may not end up buffering some
of the TLS handshake before the recv call, but there's no
guarantees).

Also add tests of the type parse(build(Info)), including
for testing the TLVs and the padding/checksum verification
options.

Using test cases from the spec and tomciopp/proxy_protocol.
Many more tests are needed, especially for the TLV part and
for the error conditions.

In addition to cleaning when ranch:stop_listener/1 is called, we
also need to clean when we detect the supervisor is going away
for normal reasons, because the supervisor might be in another
application's supervision tree.

Note that there might be a short delay in this case before the
cleanup is done, due to using monitors for detection.