The new code is only compiled in when building with -DUSE_SE_ADD, to
simplify comperative benchmarking.
Subtraction is implemented as addition of the negated second operand.
The operation is split into 2 steps:
1) Processing of low BcDig array elements present in only one
operand (only if the rdx values are different).
2) Addition or subtraction of 2 values with same effective rdx
values.
There are 4 cases for the first step, dependingg on the signs and
magnitudes of the 2 operands. The low end BcDig elements are either
copied unchanged or as their complement from the operand with higher
rdx to the corresponding array elements of the result. (These 4 caes
can be combined into 3 cases by operating on left and right operands
instead of a and b.)
The second step consists of addition of the two operands or the
subtraction of the smaller from the larger value, depending on whether
the signs of the operands do match or not.
The addition or subtraction of BcDig values is inlined in optimized
form by gcc and clang, leading to elimination of constant arguments.
This version is significantly shorter than the two functions it
replaces, if comments are not included in the line count. This is
due to less code replicated in both functions. The invocations in
bc_num_add and bc_num_sub are also simplified (no need for a function
pointer).
This code is significantly faster when compiling with gcc (in the
order of 2% for make test when built with gcc-9.1 and -O3 -flto),
but only slightly faster when built with clang.

The addDigits function is functionally equivalent with addDigit, but
allows simpler code and more error checking. The carry is passed by
reference as an in-out parameter. Passing of 0 as one of the arguments
to addition/subtraction will lead to optimized code and elimination of
redundant operations due to inlining of the small function.
These functions are also slightly more efficient, since they work with
values verified (by assertions) not to overflow a BcDig (and thus do
not depend on BcBigDig variables).
A number of asserts are provided to detect unexpected overflow from
out-of-range parameters. Fuzzing has been performed to make sure that
these assertions are satisfied for all uses of these functions with
all parameters. Care has been taken to make sure that both functions
operate correctly on signed or unsigned BcDig (in case the type was
changed to unsigned at some time).
The subDigits function allows to simplify subArrays and will be used
in combined implementation of bc_num_a and bc_num_s.

The sum variable is known to have some head-room beyond the product of
two BcDig values.
Since it is known to be larger than 2 * BC_BASE_POW^2, the test for
overflow can be against BC_BASE_POW^2 in the loop, removing the div
and mod operations from nearly all iterations.
Only a single div and mod has to be performed after termination of
the loop to get the correct results.

This bug was that whenever a void function was called, the return value,
void value, was left on the stack. Because of the way bc works, this was
never a problem, but I figured it out while laying in bed, and well, I
had to fix it.

This bug was that a void val was allowed to be passed to a function. The
second test is actually to test that void vals are not allowed where
actual values are needed.

This bug is that if a var needed to be pushed, and it wasn't last, the
var was pulled before the type check happened. This caused an assert to
(rightly) fire. The type check was moved before, and it all went away.
As said in the tag line, this commit also adds the file generated by afl
that triggered the bug.

This test was inspired by a patch to the bc in busybox. Apparently,
busybox got string execution wrong when the top of the stack was a
number. I added this test to test for that, just in case.