GNU as does not accept bics with two register operands but instead
requires three register operands.  However, clang assembles the bics
instruction to ands anyway, so just use ands directly.

Reviewed by:	fuz
Differential Revision:	https://reviews.freebsd.org/D55155

Reviewed by:	andrew, imp
Approved by:	markj (mentor)
Differential Revision:	https://reviews.freebsd.org/D45670
MFC after:	1 month

Differential Revision:	https://reviews.freebsd.org/D45670
Reviewed by:	imp
Approved by:	markj (mentor)
MFC after:	1 month

Both files are used by kernel and userspace.
Move them to sys/crypto where they belong.

No functional changes intended.

In preparation of D45670.

Reviewed by:	markj
Approved by:	markj (mentor)
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D52909

Approved by:	markj (mentor)
MFC after:	1 week

Following jrtc27@'s fix of the transcribed code, it seems to work
fine now.

See also:	207f3b2b25eaa0f9d32699e664b139e5e40e5450

This source was manually transcribed from Go's assembly syntax into
FreeBSD's. Some differences exist (e.g. around stack frame allocation,
but also some upstream LEAL instructions were replaced with ADDL here as
getting the 64-bit super-registers of 32-bit isn't so doable, unlike Go)
that were intended, but a few errors crept in. Fix these, found by
comparing post-processed disassembly[1] (handling the ADDL difference
above, and due to Go's assembler not optimising VP[X]OR encoding by
commuting operands when it would give rise to a 2-byte VEX prefix) of a
built copy of the corresponding Go source against ours.

[1] In Vim:
    %g/\<vpx\?or\>/s/\(%ymm\([89]\|1[0-5]\)\), %ymm\([0-7]\), %ymm/%ymm\3, \1, %ymm/g
    (to commute the VP[X]OR operands as LLVM does)
    %s/\<leal\>\([[:space:]]\+\)(%r\(..\),%r\(..\)), %e\2/addl\1%e\3, %e\2/
    (to convert LEAL to ADDL in the cases we do)
    %s/%e12\>/%r12d/g
    (as the previous conversion turns %r12 into %e12 not %r12d)

Fixes:	8b4684afcde3 ("lib/libmd: add optimised SHA1 implementations for amd64")

Seems like there is a bug lurking somewhere in the code.  This was not
caught during my testing.  Disable the affected kernel for now while I
figure out what is wrong with it.

To reproduce, run

    jot -s '' -b 'a' -n 1000000 | sha1

This should yield 34aa973cd4c4daa4f61eeb2bdbad27316534016f, but gives
fe161a71d7941e3d63a9cacadc4f20716a721944 with the broken code.  Only the
amd64/avx2 kernel is affected, the others seem to operate correctly.

Reported by:	olivier
Fixes:		8b4684afcde3930eb49490f0b8431c4cb2ad9a46

This provides a scalar implementation and one using the SHA1
instruction set extensions.

For the scalar implementation, the w array is kept in registers,
speeding up the whole operations. For a 10 GiB file on my Windows
2023 Dev Kit (ARM Cortex A78C / ARM Cortex X1C):

Performance core:
    pre     43.1s   (238 MB/s)
    generic 41.3s   (247 MB/s)
    scalar  35.0s   (293 MB/s)
    sha1    12.8s   (800 MB/s)

Efficiency core:
    pre     54.2s   (189 MB/s)
    generic 55.9s   (183 MB/s)
    scalar  43.0s   (238 MB/s)
    sha1    16.2s   (632 MB/s)

Reviewed by:	getz
Differential Revision:	https://reviews.freebsd.org/D45444

Three implementations are provided: one using just scalar
instructions, one using AVX2, and one using the SHA instructions
(SHANI).  The AVX2 version uses a complicated multi-block carry
scheme described in an Intel whitepaper; the code was
carefully transcribed from the implementatio shipped with the
Go runtime.  The performance is quite good.  From my Tiger Lake
based NUC:

old:    16.7s ( 613 MB/s)
scalar: 14.5s ( 706 MB/s)
avx2:   10.5s ( 975 MB/s)
shani:   5.6s (1829 MB/s)

Reviewed by:	getz
Obtained from:	https://github.com/golang/go/blob/b0dfcb74651b82123746273bbf6bb9988cd96e18/src/crypto/sha1/sha1block_amd64.s
Differential Revision:	https://reviews.freebsd.org/D45444