I claim the check can be removed but I don't want to touch this
stable and well-tested code.

On the way, we fix grammar in another comment.

Co-authored-by: Tim Ruffing <crypto@timruffing.de>

fa4d6c7 ci/cirrus: Add native ARM64 persistent workers (MarcoFalke)
2262d0e ci/cirrus: Bring back skeleton .cirrus.yml without jobs (Tim Ruffing)

Pull request description:

ACKs for top commit:
  real-or-random:
    ACK fa4d6c7
  hebasto:
    re-ACK fa4d6c7, only last two commits have been squashed since my recent [review](bitcoin-core/secp256k1#1426 (review)).

Tree-SHA512: d1fee99d54a41a4126f7eb72695a56137c925dc9ce7cd692a60ea1262ac0789bbd6aa4e4dfc030f0d97d06aeeae0724a5f2d794a85ff533c6cf3cd215f6a4b7a

We're not solely using cirrus anymore and github already displays the CI status
at a different location.

5dab0ba README: remove CI badge (Jonas Nick)

Pull request description:

ACKs for top commit:
  sipa:
    utACK 5dab0ba
  real-or-random:
    utACK 5dab0ba

Tree-SHA512: 56730fa8067cc48b8e5af6fc21b0cd6c47f615c5ebba9edcf29ca5eaf7b2359662a9af219612e80688d8f8939649c7c3c26136c0442ba47d56251a0d92cf984a

Co-authored-by: Jonas Nick <jonasd.nick@gmail.com>
Co-authored-by: Tim Ruffing <crypto@timruffing.de>

* add test case for a=infinity

  The corresponding ecmult_const branch was not tested before this commit.

* add test for edge cases

Based on the surrounding asserts, 112 bits before this line, and 61 bits after this line, this assertion should be 113 bits.  Notably the commensurate line in secp256k1_fe_sqr_inner is correctly assert to be 113 bits.

…gorithm

355bbdf Add changelog entry for signed-digit ecmult_const algorithm (Pieter Wuille)
21f49d9 Remove unused secp256k1_scalar_shr_int (Pieter Wuille)
115fdc7 Remove unused secp256k1_wnaf_const (Pieter Wuille)
aa9f3a3 ecmult_const: add/improve tests (Jonas Nick)
4d16e90 Signed-digit based ecmult_const algorithm (Pieter Wuille)
ba523be make SECP256K1_SCALAR_CONST reduce modulo exhaustive group order (Pieter Wuille)
2140da9 Add secp256k1_scalar_half for halving scalars (+ tests/benchmarks). (Pieter Wuille)

Pull request description:

  Using some insights learned from #1058, this replaces the fixed-wnaf ecmult_const algorithm with a signed-digit based one. Conceptually both algorithms are very similar, in that they boil down to summing precomputed odd multiples of the input points. Practically however, the new algorithm is simpler because it's just using scalar operations, rather than relying on wnaf machinery with skew terms to guarantee odd multipliers.

  The idea is that we can compute $q \cdot A$ as follows:
  * Let $s = f(q)$, for some function $f()$.
  * Compute $(s_1, s_2)$ such that $s = s_1 + \lambda s_2$, using `secp256k1_scalar_lambda_split`.
  * Let $v_1 = s_1 + 2^{128}$ and $v_2 = s_2 + 2^{128}$ (such that the $v_i$ are positive and $n$ bits long).
  * Computing the result as $$\sum_{i=0}^{n-1} (2v_1[i]-1) 2^i A + \sum_{i=0}^{n-1} (2v_2[i]-1) 2^i \lambda A$$ where $x[i]$ stands for the *i*'th bit of $x$, so summing positive and negative powers of two times $A$, based on the bits of $v_1.$

  The comments in `ecmult_const_impl.h` show that if $f(q) = (q + (1+\lambda)(2^n - 2^{129} - 1))/2 \mod n$, the result will equal $q \cdot A$.

  This last step can be performed in groups of multiple bits at once, by looking up entries in a precomputed table of odd multiples of $A$ and $\lambda A$, and then multiplying by a power of two before proceeding to the next group.

  The result is slightly faster (I measure ~2% speedup), but significantly simpler as it only uses scalar arithmetic to determine the table lookup values. The speedup is due to the fact that no skew corrections at the end are needed, and less overhead to determine table indices. The precomputed table sizes are also made independent from the `ecmult` ones, after observing that the optimal table size is bigger here (which also gives a small speedup).

ACKs for top commit:
  jonasnick:
    ACK 355bbdf
  siv2r:
    ACK 355bbdf
  real-or-random:
    ACK 355bbdf

Tree-SHA512: 13db572cb7f9be00bf0931c65fcd8bc8b5545be86a8c8700bd6a79ad9e4d9e5e79e7f763f92ca6a91d9717a355f8162204b0ea821b6ae99d58cb400497ddc656

…shot compilers

8185e72 ci: Ignore internal errors in snapshot compilers (Hennadii Stepanov)

Pull request description:

  It was discussed on today's IRC meeting.

ACKs for top commit:
  real-or-random:
    ACK 8185e72

Tree-SHA512: 0f41ca8303bd3d6efefcd3a544c7bd7dfcf464c57c779c876da4a77cacd262e6c963449d493fdf5a641b0d10b655c8c67fe8a147145b6533328d7bf5344313e1

With this in place, we no-longer see warnings like the following:
```bash
/usr/lib/gcc-cross/arm-linux-gnueabihf/12/../../../../arm-linux-gnueabihf/bin/ld: warning: field_10x26_arm.o: missing .note.GNU-stack section implies executable stack
/usr/lib/gcc-cross/arm-linux-gnueabihf/12/../../../../arm-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
```

Should close #1434.

These temporaries seem to been inadvertently changed to signed during a refactoring.  Generally, bit shifting is frowned upon for signed values.

These changes bring the checks to the same values used at the corresponding positions in secp256k1_fe_sqr_inner.

…ed in secp256k1_fe_sqr_inner

1027135 Return temporaries to being unsigned in secp256k1_fe_sqr_inner (roconnor-blockstream)

Pull request description:

  These temporaries seem to been inadvertently changed to signed during a refactoring.  Generally, bit shifting is frowned upon for signed values.

ACKs for top commit:
  sipa:
    utACK 1027135
  real-or-random:
    utACK 1027135

Tree-SHA512: a9fefe4b146163209662cd435422beb3c9561eb9e83110454184f70df2292992f39ec1971143428e039a80cad2f6285db74de2f059e877ad8756ff739269b67a

…or non-exec stack

33dc7e4 asm: add .note.GNU-stack section for non-exec stack (fanquake)

Pull request description:

  With this in place, we no-longer see warnings like the following:
  ```bash
  /usr/lib/gcc-cross/arm-linux-gnueabihf/12/../../../../arm-linux-gnueabihf/bin/ld: warning: field_10x26_arm.o: missing .note.GNU-stack section implies executable stack
  /usr/lib/gcc-cross/arm-linux-gnueabihf/12/../../../../arm-linux-gnueabihf/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
  ```

  Should close #1434.

ACKs for top commit:
  sipa:
    utACK 33dc7e4
  real-or-random:
    utACK 33dc7e4

Tree-SHA512: f75ded8d971f54d1e871bcc4d815ba367b3e154eea2f18309ecaf9053e22f986bfffcf28418367f8055b65a5a0b245fee045adfcb63a2196df5e2f3aa6c97b89

Widely available versions of GCC and Clang beat our field asm on -O2.
In particular, GCC 10.5.0, which is Bitcoin Core's current compiler
for official x86_64 builds, produces code that is > 20% faster for
fe_mul and > 10% faster for signature verification (see #726).

These are the alternatives to this PR:

We could replace our current asm with the fastest compiler output
that we can find. This is potentially faster, but it has multiple
drawbacks:
 - It's more coding work because it needs detailed benchmarks (e.g.,
   with many compiler/options).
 - It's more review work because we need to deal with inline asm
   (including clobbers etc.) and there's a lack of experts reviewers
   in this area.
 - It's not unlikely that we'll fall behind again in a few compiler
   versions, and then we have to deal with this again, i.e., redo the
   benchmarks. Given our history here, I doubt that we'll revolve
   this timely.

We could change the default of the asm build option to off. But this
will also disable the scalar asm, which is still faster.

We could split the build option into two separate options for field
and scalar asm and only disable the field asm by default. But this
adds complexity to the build and to the test matrix.

My conclusion is that this PR gets the low-hanging fruit in terms of
performance. It simplifies our code significantly. It's clearly an
improvement, and it's very easy to review. Whether re-introducing
better asm (whether from a compiler or from CryptOpt) is worth the
hassle can be evaluated separately, and should not hold up this
improvement.

Solves #726.

because we don't know whether it's an optimization.

…internal

1ddd76a bench: add --help option to bench_internal (Sebastian Falbesoner)

Pull request description:

  While coming up with commands for running the benchmarks for issue bitcoin-core/secp256k1#726 (comment), I noticed that in contrast to `bench{_ecmult}`, `bench_internal` doesn't have a help option yet and figured it would be nice to have one. A comparable past PR is bitcoin-core/secp256k1#1008. Benchmark categories appear in the same order as they are executed, the concrete benchmark names in parantheses per category are listed in alphabetical order.

ACKs for top commit:
  real-or-random:
    utACK 1ddd76a
  siv2r:
    ACK 1ddd76a, tested the `--help` option locally, and it works as expected.

Tree-SHA512: d117641a5f25a7cbf83881f3acceae99624528a0cbb2405efdbe1a3a2762b4d6b251392e954aaa32f6771069d31143743770fccafe198084c12258dedb0856fc

…_mul_inner

dcdda31 Tighten secp256k1_fe_mul_inner's VERIFY_BITS checks (Russell O'Connor)
8e2a5fe correct assertion for secp256k1_fe_mul_inner (roconnor-blockstream)

Pull request description:

  Based on the surrounding asserts, 112 bits before this line, and 61 bits after this line, this assertion should be 113 bits.  Notably the commensurate line in secp256k1_fe_sqr_inner is correctly assert to be 113 bits.

ACKs for top commit:
  real-or-random:
    ACK dcdda31 tested with asm disabled

Tree-SHA512: c35170e37d9a6d1413dd625032028129ab2eccee7da86697ab9641b68ad78efd7251953d51e7acaefd14888d3fd61877f9f05349c44f6fc0133ce9b3921b0e1a

As suggested in issue #1381, this will make things simpler and
improve code readability, as we don't need to force omitting of
evaluations on a case-by-case basis anymore and hence can remove
lots of `#ifdef VERIFY`/`#endif` lines (see next commit). Plus,
VERIFY_CHECK behaves now identical in both non-VERIFY and coverage mode,
making the latter not special anymore and hopefully decreasing
maintenance burden. The idea of "side-effect safety" is given up.

Note that at two places in the ellswift module void-casts of return
values have to be inserted for non-VERIFY builds, in order to avoid
   "variable ... set but not used [-Wunused-but-set-variable]"
warnings.

Now that the `VERIFY_CHECK` compiles to empty in non-VERIFY mode, blocks
that only consist of these macros don't need surrounding `#ifdef VERIFY`
conditions anymore.

At some places intentional blank lines are inserted for grouping and
better readadbility.

By providing an uppercase variant of these verification functions, it is
better visible that it is test code and surrounding `#ifdef VERIFY`
blocks can be removed (if there is no other code around that could
remain in production mode), as they don't serve their purpose any more.

At some places intentional blank lines are inserted for grouping and
better readadbility.

By providing an uppercase variant of these verification functions,
it is better visible that it is test code.

As the fields r->x and r->y are set immediately after (three lines
below), there is no need to clear them.

This define was seemingly introduced for VERIFY mode code with side
effects (for setup purposes), that should just be executed without any
checks. The same can be achieved by putting it in an `#if VERIFY` block,
so we can remove it.

…ECK and #ifdef VERIFY (issue #1381)

bb46723 remove VERIFY_SETUP define (Sebastian Falbesoner)
a3a3e11 remove unneeded VERIFY_SETUP uses in ECMULT_CONST_TABLE_GET_GE macro (Sebastian Falbesoner)
a0fb68a introduce and use SECP256K1_SCALAR_VERIFY macro (Sebastian Falbesoner)
cf25c86 introduce and use SECP256K1_{FE,GE,GEJ}_VERIFY macros (Sebastian Falbesoner)
5d89bc0 remove superfluous `#ifdef VERIFY`/`#endif` preprocessor conditions (Sebastian Falbesoner)
c2688f8 redefine VERIFY_CHECK to empty in production (non-VERIFY) mode (Sebastian Falbesoner)

Pull request description:

  As suggested in #1381, this PR reworks the policy for VERIFY_CHECK and when to use #ifdef VERIFY, by:
  - redefining VERIFY_CHECK to empty in production (non-VERIFY) mode
  - removing many then superflous #ifdef VERIFY blocks (if they exclusively contained VERIFY_CHECKs)
  - introducing uppercase macros around verify_ functions and using them for better readabiliy

  What is _not_ included yet is the proposed renaming from "_check" to "_assert":
  > And while we're touching this anyway, we could consider renaming "check" to "assert", which is a more precise term. (In fact, if we redefine VERIFY_CHECK to be empty in production, we have almost reimplemented assert.h...)

  This should be easy to achieve with simple search-and-replace (e.g. using sed), but I was hesitant as this would probably case annoying merge conflicts on some of the open PRs. Happy to add this if the rename if desired (#1381 didn't get any feedback about the renaming idea yet).

ACKs for top commit:
  stratospher:
    ACK bb46723.
  real-or-random:
    utACK bb46723

Tree-SHA512: 226ca609926dea638aa3bb537d29d4fac8b8302dcd9da35acf767ba9573e5221d2dae04ea26c15d80a50ed70af1ab0dca10642c21df7dbdda432fa237a5ef2cc

f07cead build: Don't call assembly an optimization (Tim Ruffing)
2f0762f field: Remove x86_64 asm (Tim Ruffing)

Pull request description:

ACKs for top commit:
  sipa:
    utACK f07cead
  theStack:
    ACK f07cead
  jonasnick:
    ACK f07cead

Tree-SHA512: df7f895ab8ab924c5f8f01c35d0cd2f65d5c947c5ab5325787d169c5b202834ab8aa5d85dedb25839fff3f518097fe8cf8e837d3c1918e5f039ddd6ddf4187da

04af0ba Replace ge_equals_ge[,j] calls with group.h equality calls (Pieter Wuille)
60525f6 Add unit tests for group.h equality functions (Pieter Wuille)
a47cd97 Add group.h ge/gej equality functions (Pieter Wuille)

Pull request description:

  This pull requests removes the test-only functions `ge_equals_ge` and `ge_equals_gej`, and replaces them with proper group.h functions `secp256k1_ge_eq_var` and `secp256k1_gej_eq_ge_var` (mimicking the existing `secp256k1_gej_eq_var` function).

  This drops some of the arbitrary and undocumented magnitude restristrictions these functions have, makes them properly tested on their own, and makes their semantics cleaner (I'm always left checking whether `ge_equals_ge` does a `CHECK` internally or whether it returns a value...).

ACKs for top commit:
  real-or-random:
    utACK 04af0ba
  stratospher:
    ACK 04af0ba.

Tree-SHA512: 49bc409ffa980144d1305c9389a846af45f0a97bfec19d016929056aa918c6a9f020dbe8549f5318fa8e6a4108621cc3cce60331aa0634f84619a1104d20a62a

libsecp256k1 has become more than a library for just ECDSA and key tweaking.

…emove x86_64 asm"

d2e36a2 changelog: add entry for "field: Remove x86_64 asm" (Jonas Nick)

Pull request description:

ACKs for top commit:
  real-or-random:
    ACK d2e36a2

Tree-SHA512: c4bffb921c58185b0a43546977449f3c53c21230d6d32cf5d5ccf563b196ec3d0370a0b87de5b334e5190ff91da598dd0bbebbb5c9d7bef9ec8c0679c3b6c702

0e5ea62 CONTRIBUTING: add some coding and style conventions (Jonas Nick)
1a432cb README: update first sentence (Jonas Nick)
0922a04 docs: move coverage report instructions to CONTRIBUTING (Jonas Nick)
76880e4 Add CONTRIBUTING.md including scope and guidelines for new code (Jonas Nick)

Pull request description:

  Following offline discussions, this PR documents the scope of the library and the requirements for adding new modules. I think this fixes most of #997. It also updates the README very slightly.

  In addition, I added some coding conventions that I remembered explaining to new contributors in the past year. Even though it's far from exhaustive, I think this is an easy improvement to the CONTRIBUTING.md. Feel free to suggest more conventions.

ACKs for top commit:
  sipa:
    ACK 0e5ea62
  real-or-random:
    ACK 0e5ea62

Tree-SHA512: ffdbab22982fd632de92e81bd135f141ac86e24cc0dcfc0e1ae12b0d2a2e4f91377ab2c0cc440cb919889eaed8bfc1447b880fa1430fd771b956f2af0fe3766e

…arsing ECDSA sigs

e02f313 Add comment on length checks when parsing ECDSA sigs (Tim Ruffing)

Pull request description:

  I claim the check can be removed but I don't want to touch this
  stable and well-tested code.

  On the way, we fix grammar in another comment.

ACKs for top commit:
  sipa:
    ACK e02f313
  RandyMcMillan:
    ACK e02f313

Tree-SHA512: f82691a8f5db82a1e9683e52ce8e952ebd56b476a2817c5a876ce4638254b7b4ac93175318fb59598ed5532f33433951d75afea03724ef4419c3e1bd12ca8c20

…mod doc

3928b7c doc: improve secp256k1_fe_set_b32_mod doc (Coding Enthusiast)

Pull request description:

  As discussed in #1453
  This only changes the `secp256k1_fe_impl_set_b32_mod` comment since I think `secp256k1_fe_set_b32_limit` doc is clear enough.

ACKs for top commit:
  sipa:
    ACK 3928b7c
  theStack:
    ACK 3928b7c

Tree-SHA512: ad62c1b72d6a487473b182e6aadc7765711385add8c6576bf15c2015db82721f19e3d635f7a29316c2ee7e3c73bc55e2cd4f46ec13180be93d6fe8641f47e7d2

Co-authored-by: Tim Ruffing <crypto@timruffing.de>

…process

74a4d97 doc: Add ABI checking with `check-abi.sh` to the Release Process (Hennadii Stepanov)
e7f830e Add `tools/check-abi.sh` (Hennadii Stepanov)

Pull request description:

ACKs for top commit:
  real-or-random:
    ACK 74a4d97 it compares the right commits now
  jonasnick:
    re-Concept ACK 74a4d97

Tree-SHA512: bcca5246837f899d43ced3b0099a8e123f4fd2db7d15684bda22657649521db0c87f76696bfbd93b4dfdec6c4851e99c26c7e37cc5a1a78e9b1a296850a067fe

672053d release: prepare for 0.4.1 (Jonas Nick)

Pull request description:

ACKs for top commit:
  sipa:
    ACK 672053d
  real-or-random:
    ACK 672053d
  hebasto:
    ACK 672053d

Tree-SHA512: de78fd4588061ffc9b869d86c6d639dce06ed215c0614a888827054014c073a97b106268e5d5773967f9407c70ddc0f27326ee9c858dce5d52af7f33d2d46b69

…r 0.4.1

4b2e06f release cleanup: bump version after 0.4.1 (Jonas Nick)

Pull request description:

ACKs for top commit:
  hebasto:
    ACK 4b2e06f
  real-or-random:
    ACK 4b2e06f

Tree-SHA512: b1c764f0f13b259bcd6f2a8988dd92cefe7791dfed337c8d54bd148ea0b93dc1c931c9ff310fd5503432250a8359dd7b09dea6e8f66c0300c47a68349077d8f8

Without this commit, the res[i][1] test vectors are unused. They were introduced
to test the correctness of scalar_sqr(x) and scalar_mul(x, x). These tests were
deleted as part of removing scalar_sqr in commit
5437e7b.

d77170a Fix typos (shuoer86)

Pull request description:

  Fix some typos caught by spell checker

ACKs for top commit:
  real-or-random:
    utACK d77170a

Tree-SHA512: 18722459b0b8d906ad93dd0f159b0a70a338d08c121ce6523bb6be70be33febdffa5241efc000acf18c70a845795b0582599a71d6dd25b663fee1358c8d38c85

3dbfb48 tests: restore scalar_mul test (Jonas Nick)

Pull request description:

  Without this commit, the res[i][1] test vectors are unused. They were introduced to test the correctness of scalar_sqr(x) and scalar_mul(x, x). These tests were deleted as part of removing scalar_sqr in commit
  [5437e7b](bitcoin-core/secp256k1@5437e7b#diff-c2d5f1f7616875ab71cd41b053cfb428696988ff89642b931a0963d50f34f7e8L2195).

  Discovered in bitcoin-core/secp256k1#1463 by Coding-Enthusiast (thanks!).

ACKs for top commit:
  real-or-random:
    utACK 3dbfb48

Tree-SHA512: 914e08db3efaa1cef546a9730096e740478c422d41fedb2b71ec3a7ea962f81740a05dc7e7c1fb191088f6d38b5690479c7d0864ca8abf2b2e9c4334f03ca605

Replaces "ctx: a secp256k1 context object" with "ctx: pointer to a context
object". Also removes the word "existing".

This gets rid of an untested code path. Resolves #1352.

secp256k1_ge_storage is a struct with two secp256k1_fe_storage fields.
The C standard allows the compiler to add padding between the fields and
at the end of the struct, but no sane compiler in the end would do this:
The only reason to add padding is to ensure alignment, but such padding
is never necessary between two fields of the same type.

Similarly, secp256k1_fe_storage is a struct with a single array of
uintXX_t. No padding is allowed between array elements. Again, C allows
the compiler to insert padding at the end of the struct, but there's no
absolute reason to do so in this case.

For the uintXX_t itself, this guaranteed to have no padding bits, i.e.,
it's guaranteed to have exactly XX bits.

So I claim that for any existing compiler in the real world,
sizeof(secp256k1_ge_storage) == 64.

This also splits the big "&&" expression into separate expressions. If
we ever see an assertion fail, the error message will tell it precisely
which one failed.

da7bc1b include: in doc, remove article in front of "pointer" (Jonas Nick)
aa3dd52 include: make doc about ctx more consistent (Jonas Nick)
e3f6900 include: remove obvious "cannot be NULL" doc (Jonas Nick)

Pull request description:

ACKs for top commit:
  sipa:
    ACK da7bc1b
  real-or-random:
    ACK da7bc1b

Tree-SHA512: 809f312fa0cd1e9502ac79b8a1c502b87e6dfc2db8ad6bbd96d7ddbdaadad0c3b6110fa704b770c353cd34d5bf5547541cbb5f2779425d7419b584e721c854c2

…k1_ge_storage) == 64 code path

ba5d72d assumptions: Use new STATIC_ASSERT macro (Tim Ruffing)
e53c2d9 Require that sizeof(secp256k1_ge_storage) == 64 (Tim Ruffing)
d0ba2ab util: Add STATIC_ASSERT macro (Tim Ruffing)

Pull request description:

  This gets rid of an untested code path. Resolves bitcoin-core/secp256k1#1352.

  This is a bit opinionated in the sense that it adds a static assertion where it's needed in `secp256k1_pubkey_save` and `secp256k1_pubkey_load`. I think this is justified in this case. It helps the reviewer verify that these functions are correct.

  See individual commit messages.

ACKs for top commit:
  sipa:
    utACK ba5d72d
  jonasnick:
    ACK ba5d72d

Tree-SHA512: 2553c0610b62bcda6d4ef26eb26b5b2e07acf723bcd299691a2d02da57af22b8763f63c2d4adb17d30de8825b6157be6e4f0398147854fbabdf8b865fb0b5c88

b37fdb2 check-abi: Minor UI improvements (Tim Ruffing)
ad5f589 check-abi: Default to HEAD for new version (Tim Ruffing)
9fb7e2f release process: Style and formatting nits (Tim Ruffing)
e7053d0 release process: Add email step (Tim Ruffing)
429d21d release process: Run sanity checks on release PR (Tim Ruffing)

Pull request description:

ACKs for top commit:
  hebasto:
    ACK b37fdb2.
  jonasnick:
    ACK b37fdb2

Tree-SHA512: 6e18a5b897d29a3dd3a73ba81623dd91c04fa6730fb56374b924dc84baaec8c55d0c689ee1a41dab9a03ccd566082fc59ffb5d68cafd536a136fc7aaac2d8ef5

This also makes the order in which module options are processed
consistent between CMake and autotools (the reverse order of the listing
printed to stdout).

… dependencies

e682267 build: Error if required module explicitly off (Tim Ruffing)
89ec583 build: Clean up handling of module dependencies (Tim Ruffing)

Pull request description:

  This is a cleanup which makes it easier to add further modules with dependencies, e.g., in #1452. The diff looks larger than it is because I also reordered the modules and made the order consistent between CMake and autotools.

  (We noticed that the current logic could be improved in BlockstreamResearch#275.)

ACKs for top commit:
  jonasnick:
    ACK e682267
  hebasto:
    ACK e682267.

Tree-SHA512: 040e791e5b5b9b8845a39632633a45ca759391455910bdefba2b7b77c6340e65df6eda18199ae2ad65c30ee2fc6630471437aec143c26fe09ae4c11409a37622

… configure option

42f8c51 cmake: Add `SECP256K1_LATE_CFLAGS` configure option (Hennadii Stepanov)

Pull request description:

  This PR enables users to override compiler flags that have been set by the CMake-based build system, such as warning flags.

  The Autotools-based build system has the same feature out-of-the-box.

  See more details [here](bitcoin-core/secp256k1#1235 (comment)).

  Here are some examples of the new option usage:
  ```
  cmake -S . -B build -DSECP256K1_LATE_CFLAGS="-Wno-extra -Wlong-long"
  ```

  ```
  cmake -S . -B build -DSECP256K1_BUILD_EXAMPLES=ON -DSECP256K1_LATE_CFLAGS=-O1
  cmake --build build
  ...
  In function ‘secp256k1_ecmult_strauss_wnaf’,
      inlined from ‘secp256k1_ecmult’ at /home/hebasto/git/secp256k1/src/ecmult_impl.h:353:5:
  /home/hebasto/git/secp256k1/src/ecmult_impl.h:291:5: warning: ‘aux’ may be used uninitialized [-Wmaybe-uninitialized]
    291 |     secp256k1_ge_table_set_globalz(ECMULT_TABLE_SIZE(WINDOW_A) * no, state->pre_a, state->aux);
        |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In file included from /home/hebasto/git/secp256k1/src/secp256k1.c:29:
  /home/hebasto/git/secp256k1/src/ecmult_impl.h: In function ‘secp256k1_ecmult’:
  /home/hebasto/git/secp256k1/src/group_impl.h:174:13: note: by argument 3 of type ‘const secp256k1_fe *’ to ‘secp256k1_ge_table_set_globalz’ declared here
    174 | static void secp256k1_ge_table_set_globalz(size_t len, secp256k1_ge *a, const secp256k1_fe *zr) {
        |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In file included from /home/hebasto/git/secp256k1/src/secp256k1.c:30:
  /home/hebasto/git/secp256k1/src/ecmult_impl.h:345:18: note: ‘aux’ declared here
    345 |     secp256k1_fe aux[ECMULT_TABLE_SIZE(WINDOW_A)];
        |                  ^~~
  ...
  ```

  Please note that in the last case providing `env CFLAGS=-O1` or `-DCMAKE_C_FLAGS=-O1` won't work.

ACKs for top commit:
  real-or-random:
    ACK 42f8c51

Tree-SHA512: 2b152e420a4a8ffd5f67857de03ae5ba9f2223e535ac01a867c1025e0619180d8255fdd1e5fb8279b290f0a1c96bcc874043ef968fcd99b1ff4e13041a91b1e1

5814d84 07687e8 10e6d29 d3e29db e2c9888 4197d66 5e9a4d7 77af1da 1a81df8 1ad5185 efe85c7 79e0945 d373bf6 74b7c3b a9db9f2 4437886 3bf4d68 e4af41c ' into temp-merge-1249

Like upstream bitcoin-core/secp256k1#1476 .

It was a verbatim copy of secp256k1_ec_pubkey_cmp.

Remove explicity VERIFY_CHECKs in keyaggcoef_internal since normalization should
be checked in the fe_* functions.