Many type object initializations labeled a field "tp_size" in the
comment, but the name of that field is tp_basicsize..
(cherry picked from commit 0e0bc4e2)
Co-authored-by: Peter Eisentraut <peter@eisentraut.org>

* help(hashlib) didn't work because of incorrect module name in blake2b and
  blake2s classes.
* Constructors blake2*(), sha3_*(), shake_*() and keccak_*() incorrectly
  accepted keyword argument "string" for binary data, but documented as
  accepting the "data" keyword argument. Now this parameter is positional-only.
* Keyword-only parameters in blake2b() and blake2s() were not documented as
  keyword-only.
* Default value for some parameters of blake2b() and blake2s() was None,
  which is not acceptable value.
* The length argument for shake_*.digest() was wrapped out to 32 bits.
* The argument for shake_128.digest() and shake_128.hexdigest() was not
  positional-only as intended.
* TypeError messages for incorrect arguments in all constructors sha3_*(),
  shake_*() and keccak_*() incorrectly referred to sha3_224.

Also made the following enhancements:

* More accurately specified input and result types for strings, bytes and
  bytes-like objects.
* Unified positional parameter names for update() and constructors.
* Improved formatting.
(cherry picked from commit f1d36d8e)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

All Blake2 params have to be encoded in little-endian byte order. For
the two multi-byte integer params, leaf_length and node_offset, that
means that assigning a native-endian integer to them appears to work on
little-endian platforms, but gives the wrong result on big-endian. The
current libb2 API doesn't make that very clear, and @sneves is working
on new API functions in the GH issue above. In the meantime, we can work
around the problem by explicitly assigning little-endian values to the
parameter block.

See https://github.com/BLAKE2/libb2/issues/12.

Replace occurence of nested comments in blake2 reference implementation
with preprocessor directive for disabling unused code.

`blake2s-load-xop.h` is conditionally pulled in only on chips with XOP
support, among others the AMD Bulldozer. The malformed comments in the
source file breaks the build of `hashlib`'s `_blake2` on GCC 6.3.0.

Official reference code on github uses `#if` so this change should be
uncontroversial.

Rework the code choosing BLAKE2 code paths from using the optimized
variant on all x86_64 machines to using it when SSSE3 or better
supported instructions sets are available.

Firstly, this solves the problem of using pure SSE2 code path on x86_64
machines. As reported in the bug, this code is slower than the reference
code on all tested x86_64 machines. Furthermore, on Athlon64 that lacks
SSSE3, it is even 2.5 times slower than the reference code! Checking
for SSSE3 therefore ensures that the optimized implementation will only
be used when it has a chance of performing better.

Secondly, this makes it possible to use SSSE3+ optimizations on 32-bit
x86 systems. This allows for even 2 times speed gain on modern 32-bit
x86 systems (tested in a 32-bit chroot).

* Remove Setup.config
* Always define WITH_THREAD for compatibility.

possible.  Patch is writen with Coccinelle.

Issue #26798: Coverity complains about potential memcpy() of overlapped regions. It doesn't hurt to use memmove() here. CID 1372514 / CID 1372515. Upstream https://github.com/BLAKE2/BLAKE2/issues/32

blake2: silence two more warnings on platforms with size_t < uint64_t. Don't use SSE2 when cross-compiling