[RFC]: replace static memory allocation of large arrays in C benchmarks with dynamic memory allocation (tracking issue)

## Instructions

1. Read the issue description below.
2. Read the issue comment which follows the description.
3. Search the code base for a package having a C benchmark which needs updating according to the description below.
4. Follow any additional guidance specified in this issue.

## Description

This RFC proposes improving C benchmarks by moving away from static memory allocation for large arrays to dynamic memory allocation for large arrays. Static memory allocation can be problematic due to the potential for segmentation faults for systems having limited memory (see https://github.com/stdlib-js/stdlib/issues/369 for context).

In short, this RFC seeks to refactor C benchmarks from, for example,

```c
// ...

static double benchmark( int iterations, int len ) {
// ...
double x[ len ]; // <= static allocation

// ...
}

// ...
```

to

```c
// ...

static double benchmark( int iterations, int len ) {
// ...
double *x;

// ...

x = (double *) malloc( len * sizeof( double ) );

// ...

free( x );

// ...
}

// ...
```

This refactoring is demonstrated in commit https://github.com/stdlib-js/stdlib/commit/f0f8a70989b6cfdabf6b928650c50b28aab5e224.

In particular, notice three things:

1. Instead of a static allocation `x[ len ]`, we declare a pointer `*x`.
2. We perform dynamic memory allocation `x = (double *) malloc(...)`.
3. We free allocated memory `free( x )`.

## Steps

Given the relatively widespread practice of using static memory allocation in benchmarks, this RFC aims to be an open call for any contributor wanting to contribute to the project to do the following:

0. Study the changes made in commit https://github.com/stdlib-js/stdlib/commit/f0f8a70989b6cfdabf6b928650c50b28aab5e224, as this commit contains the sorts of changes that we are looking for.
1. Ensure you have setup your local development environment by following the [contributing guide](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md), including `make install-node-modules` and `make init`.
2. Find a package containing a C benchmark which performs static memory allocation of potentially large arrays. A possible global project search could use the regular expression `(?:int8_t|uint8_t|int32_t|uint32_t|int64_t|uint64_t|double|float) [a-zA-Z0-9]+\[\s*len\s*\];`. From the search results, you should be able to find a package in need of updating. You can ignore static allocations of small arrays (e.g., `int64_t shape[ 3 ];`).
3. Update the C benchmarks for that package, and **only that package**, to migrate to use dynamic memory allocation. C benchmarks can be found in the `benchmarks/c` folder of a package (if it exists).
4. Run C benchmarks locally using the command `make benchmark-c BENCHMARKS_FILTER=".*//.*"`. For example, `make benchmark-c BENCHMARKS_FILTER=".*/blas/ext/base/dfill/.*"`.
5. Commit your changes.
6. Submit a PR updating the C benchmarks for that package (and only that package).
7. For the PR title, use the following template "bench: refactor to use dynamic memory allocation in ``" where `` is the name of the package you updated (e.g., `blas/ext/base/dfill`).

**Please do NOT make extraneous changes to benchmarks. We are not interested in changing benchmarks wholesale. We are only interested in replacing static memory allocation logic with dynamic memory allocation.**

## Related Issues

- https://github.com/stdlib-js/stdlib/issues/369

## Questions

None.

### Other

- If you are interested in working on this RFC, for each pull request, **please only update the benchmarks for a single package**.
- As mentioned above, **please do NOT make extraneous changes to benchmarks. We are not interested in changing benchmarks wholesale. Nor are we interested in new "creative" changes. We are only interested in replacing static memory allocation with dynamic memory allocation.** Failure to match the behavior of the existing benchmarks and to respect this guidance will result in your PRs being automatically closed without review.
- As this is a "Good First Issue", you are **strongly encouraged** to **avoid** using AI when authoring your contribution. One of the primary intents of Good First Issues is to help introduce you to stdlib, its development environment, and the contribution process, as documented in the [contributing guide](https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md). Most new contributors are unfamiliar with stdlib and its conventions, and thus fail to appropriately use LLMs and AI when authoring contributions, most often generating AI slop and leading to wasted time. Don't be one of those people. :) Take the time to manually author your first several PRs, and, once you are intimately familiar with project conventions, you can consider leveraging AI to augment your dev tasks.

### Checklist

- [x] I have read and understood the [Code of Conduct](https://github.com/stdlib-js/stdlib/blob/develop/CODE_OF_CONDUCT.md).
- [x] Searched for existing issues and pull requests.
- [x] The issue name begins with `RFC:`.

Search the repository for the supplied regular expression and inspect one package's benchmarks/c directory, using commit f0f8a70989b6cfdabf6b928650c50b28aab5e224 as the model. Update only that package's large-array allocations, then run make benchmark-c BENCHMARKS_FILTER=".*//.*". Done means the package's C benchmarks use dynamic allocation without unrelated changes and the benchmarks run successfully.

Escrito por el modelo de indexación a partir del texto del issue.