destroying the scratch space when its alloc_size > 0 leads to an error

secp256k1_context obj is used for its error_callback function

In future, batch_context_create and batch_context_destroy will be
moved to src/ directory. Only batch_context_add_*, batch_context_verify
will be present in the schnorrsig module

batch_context_create and batch_context_destroy function are compiled
by default.

src/batch_impl: contains create and destroy function definition.

This implementation is very similar to src/scratch_impl.h

added initial example where the batch context is created and destroyed.

added batch_context_verify to the schnorrsig module

batch_ctx->rounds keeps track of number of times the scratch space was
erased by batch_add_* function. This occurs when user's inputs exceed
batch object capacity (specified during creation).

This func will be update to include the following:
[ ] randomizer generation (currently assume to be 1)
[ ] run transparent verification if batch object is full

…orrsig

batch_context_verify:
- moved this API from module/schnorrsig/main_impl.h to secp256k1.c
- hence this API will be available even if the user doesn't enable schnorrsig module

batch_context_add_schnorrsig:
- moved this API from module/schnorrsig/main_impl.h to module/schnorrsig/batch_add_impl.h
- required since this api needs the `schnorrsig_challenge` func defined in schnorrsig/main_impl.h
- hence batch_impl.h will be included after schnorrsig/main_impl.h in the secp256k1.c file

for each term added by the user, twice the number of points (and scalars)
will be added to the scratch space. One term (schnorrsig or tweak) contains:
- R, P for schnorrsig
- Q, P for tweak check

…ignment

currently the code uses `scalar_cmov` to set a scalar to the scratch space.
This can be done using `batch_ctx->scalars[i] = ai` instead since we are
not required to use constant function during verification

…on scratch

let's use the following notation:
    - len(user_terms) = number of terms added by the user to the batch object
    - len(scratch_terms) = number of points (or scalars) present on batch objects's scratch space

Previously `batch_ctx->len` was used to represent `len(user_terms)` since I assumed that
`len(scratch_terms) = 2 * len(user_terms)` is always true.
    - if user adds schnorrsig, R and P will be added to scratch
    - if user adds tweak checks, Q and P will be added to scratch

This approach will fail if the batch objects is required to verify `e*P ?= s*G`. In this case,
`len(scratch_term) = len(user_term)` since only P will be added to batch objects scratch space

`rounds` was used to track the number of times the scratch space was
cleared by batch_context_add_* for transparent verification. It will
also tell the number of terms the user entered (rounds*capacity + len).

Keeping track of this data was not worth it since the user could always
have a counter to for total number of terms entered. It also made the
`batch_verify` function look messy. Hence, decided to remove `rounds` memeber.

The side effect of removing this data memeber is setting `batch_ctx->result = 1`
during creation since we alwasy need to `&&` with `batch_ctx->result` during
verification.

If the user calls `batch_add_schnorrsig` while the batch context's scratch
space is full (i.e, batch_ctx->len = batch_ctx->capacity). The previously
allocated points and scalars will be erased to allow adding new points
and scalars (to scratch space).

this part of batch_create does performs the same operation as
`secp256k1_batch_scratch_alloc`, so calling that func instead

Adds xonly pubkey tweak check data to the batch context.
This function's algorithm is based on `secp256k1_xonly_pubkey_tweak_add_check`.

Batch context's secp256k1_sha256 object will be initialized with the tag "BIP0340/batch"

- removed `init` from the randomizer function name
- removed `tweaked_buf[33]` from `secp256k1_batch_xonlypub_randomizer`
- update documentation of `batch_context_add_*` functions

libsecp's CI tests required a newline to be present at the end of every file

- rename `n_terms` to `max_terms`
- add `static` keyword for internal function definition
- add `ARG_CHECK(batch_ctx != NULL)`

Previously:
- `batch_add_schnorrsig` API was exposed through `include/secp256k1_schnorrsig.h`.
- `batch_add_xonlypub_tweak_check` API was exposed through `include/secp256k1_extrakeys.h`.
-  These APIs also had an `#ifdef` guard to check if user enable the batch module.

Placing an `#ifdef` guard in an include file forces the user to define `ENABLE_MODULE_BATCH`
macro while compling their C program. Hence, the `batch_add_` APIs are exposed through a
new header file without any `#ifdef`. Now, the user can simply the any libsecp's header file
without worrying about defining any macro (during compilation).

(cherry picked from commit c171f0d)

(cherry picked from commit 9acd9c4)