A table of combinations of several points can be built as one chain of
additions whose z ratios bring every entry to a common z afterwards, as
is done for the odd multiples of a single point. Unlike those multiples,
combinations can be infinite, and secp256k1_gej_add_ge_var cannot carry
a chain across an infinity: it refuses an infinite input when asked for
a ratio, and reports a vanishing sum with a zero ratio.

secp256k1_ge_z holds an affine point together with the z of the
isomorphic curve it is on, which stays defined when the point is
infinite. secp256k1_ge_z_add_ge_var adds an affine point to it and
always reports a usable ratio. secp256k1_ge_z_set_infinity and
secp256k1_ge_z_verify complete the type.

The tests compare both coordinates of each result. test_gej_eq_strict
is added for that, since secp256k1_gej_eq_var cannot tell a wrong y.

A bundle is a group of ECMULT_BUNDLE_SIZE = 6 points served by one
table. Its scalars will be recoded so that the only combinations asked
of it are a sign times the sum of its first point, the anchor, and a
subset of the others, so the table holds the subset sums that contain
the anchor and a negative sign is applied at lookup.

In Gray code order each entry is the previous one plus or minus an
input point. The table is then one chain of mixed additions with a
single accumulator, a secp256k1_ge_z since an entry can be infinite,
and the chain's z ratios bring every entry to a common z. Successive
bundles extend the same chain, and
secp256k1_ecmult_bundle_table_set_globalz walks it back from the end.

A bundle index is the byte that selects what a bundle contributes: the
number of a table entry, one bit per follower, under a sign bit for the
anchor. secp256k1_ecmult_bundle_table_get_ge resolves one.
secp256k1_ecmult_bundle_table_get_ge_lambda does the same for the
lambda multiples, which share the table and differ only in x;
secp256k1_ecmult_bundle_table_lambda_x prepares those x coordinates.

An entry of a bundle table can be infinite, so the lambda lookup
carries the infinity flag, which secp256k1_ecmult_table_get_ge_lambda
has no need to do.

The halves that secp256k1_scalar_split_lambda produces are small signed
integers held as residues mod n. secp256k1_hscalar is such a half as
the integer it is, 160 bits of two's complement, so that a recoding can
add halves, complement and XOR them and read their bits with plain word
arithmetic.

The conversion is a conditional addition of 2^256 - n keyed on the
scalar's top bit. Under VERIFY the words dropped are checked to be sign
extension.

Each scalar is split by lambda, and on each side of the split the
bundle's halves are recoded together into ECMULT_BUNDLE_BITS positions:
the anchor's coefficient is +1 or -1 at every position, and each
follower's is zero or the anchor's. A position is then a sign and a
subset of the followers, which is a bundle index as the table lookups
take it.

With the halves as half-scalars, the anchor's signs are the bits of its
half u in two's complement, the top one inverted. They denote 2*u + 1,
so the anchor's scalar q is first adjusted to (q + K)/2 with
K = -(1 + lambda), which is the scalar offsetting of
secp256k1_ecmult_const_gej. A follower's presence mask comes in closed
form, ~((f + ~u) ^ u) for its half f: one addition and one XNOR, with
no pass over the positions.

130 positions are needed rather than 129, the halves of a split
reaching 0.6354*2^128 and f + ~u having to fit in two's complement of
that many bits.

secp256k1_ecmult_bundle_multi puts the pieces together: recode every
bundle's scalars, build every bundle's table on one chain and bring
them to a common z, then run ECMULT_BUNDLE_BITS positions with one
lookup and one addition per bundle on each side of the lambda split.
G is handled as in Strauss' algorithm, in the same loop.

The main loop does as many additions as Strauss' algorithm would for
the same points. The gain is in the tables, which take fewer additions
and normalizations to build and, with the indices, little more than
half the space, and in the recoding. The function's comment has the
outline of the method and the counts.

For now the number of points has to be a multiple of
ECMULT_BUNDLE_SIZE.

secp256k1_ecmult_bundle_multi now accepts any number of points from
one bundle up. The ones left over, secp256k1_ecmult_bundle_remainder
of them, get tables of odd multiples and wNAF digits as in Strauss'
algorithm, on the same chain as the bundles' tables
(secp256k1_ecmult_bundle_chain_set_globalz) and in the same main loop,
so they cost what they would have cost there.

Bundles are never partly filled: a bundle costs the main loop the same
whether full or not, so each missing point puts it further behind
Strauss' algorithm.

secp256k1_ecmult_bundle_batch is the counterpart of
secp256k1_ecmult_strauss_batch: it takes points from a callback,
allocates the bundle tables, indices and the leftover points' wNAF
state on the scratch space, and runs secp256k1_ecmult_bundle_multi.
With fewer points than fill one bundle, or if an allocation fails, the
batch goes to Strauss' algorithm.

Nothing selects it yet. It is added to the multi-point tests alongside
the other batch functions and to bench_ecmult as the bundle mode, and
the exhaustive tests run it over the small groups, where a bundle's
subset sums vanish often enough for the tables to hold infinities.

Below the Pippenger threshold, secp256k1_ecmult_multi_var now calls
secp256k1_ecmult_bundle_batch where it called
secp256k1_ecmult_strauss_batch. Batches are still sized as for
Strauss' algorithm, which is what a batch falls back to when it has
fewer points than one bundle or does not fit.

The exhaustive bundle test now goes through secp256k1_ecmult_multi_var
as well, and the bench_ecmult help text names the new default.

secp256k1_ecmult_multi_var sized the bundled algorithm's batches as
for Strauss' algorithm, which needs about 70% more space per point,
and split a call into equal batches, each of which could have points
left over.

secp256k1_bundle_scratch_size is what a batch takes, and
secp256k1_bundle_max_points a batch size, in whole bundles, such that
it and every smaller batch fit. Fewer points can need more space, a
point left over costing more than a bundled one, so room is set aside
for the worst smaller batch. Batch sizes are rounded up to whole
bundles, so only the last batch of a call has points left over.

With that, secp256k1_ecmult_bundle_batch no longer falls back to
Strauss' algorithm when an allocation fails. A scratch space too small
for batches to be sized this way still gets Strauss' algorithm, sized
as before.

The threshold was the number of points from which Pippenger's
algorithm beats Strauss' algorithm. What it now has to beat is the
bundled algorithm, which is 16% to 18% faster than Strauss' at these
sizes, so the crossover moves up.

Measured on an i7-12700H P-core at a fixed 2.3 GHz, with n points and
G, the two are equal at about 181 points when built with gcc 16.1 -O2
and at about 194 with clang 22.1 -O2. The lower of the two is taken,
which also gives some credit to Pippenger's algorithm for the smaller
scratch space it needs. On the same machine Strauss' algorithm and
Pippenger's cross at about 77 points (gcc) and 74 (clang).

This is one machine and two compilers. The value will need tuning on
more hardware.

test_ecmult_multi_batching runs twice the threshold in points, so it
now does about four times the work.