Autogenerated gotcha_map_unifycr_list.h breaks build after adding new wrapper

Nobody has claimed this yet.

### Describe the problem you're observing

After adding a new wrapper, there appears to be a Python script in client/check_fns that can/should be used to autogenerate `client/src/gotcha_map_unifycr_list.h` in order to help streamline the process and ensure GOTCHA finds all wrapped functions.

https://github.com/LLNL/UnifyCR/blob/c73a77b37c520a905b003983fef92b686468ec82/client/src/gotcha_map_unifycr_list.h#L1

This script is meant to go through all the `.c` files in client/src and grab all the wrapper signatures declared with `UNIFYCR_WRAP`. It then generates `gotcha_map_unifycr_list.h` by creating the `UNIFYCR_DEF` and adding the `gotcha_binding` to the `struct gotcha_binding_t wrap_unifycr_list[]` for each wrapper.

Either our code base has changed since this script was last used, or this is still a WIP as the autogenerated version of `gotcha_map_unifycr_list.h` has a couple subtle changes in it, causing the build to fail.

### Describe how to reproduce the problem

The steps taken can be found in [client/check_fns/README.md](https://github.com/LLNL/UnifyCR/blob/dev/client/check_fns/README.md), but it seems to be out of date in parts.

1. Each _wrap signature in the `client/src/*.c` files needs to be on one line or the `grep` in step 2 needs to be adjusted.
1a. For example, the `grep` in step 2 only grabbed line 987 here:

https://github.com/LLNL/UnifyCR/blob/c73a77b37c520a905b003983fef92b686468ec82/client/src/unifycr-sysio.c#L987-L988

2. Run the command `grep -h UNIFYCR_WRAP ../src/*.c > unifycr_list.txt` to generate `unifycr_list.txt` for the python script.
2a. The `-h` option isn't in the `README.md` but running without it ended up pre-appending the file names.
2b. Lines such as `ret = UNIFYCR_WRAP(vfprintf)(stream, format, args);` were captured by this `grep` as well. Had to manually remove them to get the script to work.

3. Run the command `python unifycr_translate.py unifycr_list` to generate `gotcha_map_unifycr_list.h`.

4. Then `cp` the new `gotcha_map_unifycr_list.h` to client/src to replace the old one.

Ran into this when working on #169 and since the build failed after following this process, the appropriate lines had to be added to `gotcha_map_unifycr_list.h` manually.

### Include any warning or errors or releveant debugging data

In attempting to build, errors similar to the following were produced:
```
In file included from ../../../client/src/unifycr.c(59):
../../../client/src/gotcha_map_unifycr_list.h(1): error: declaration is incompatible with "FILE *(*__real_fopen)(const char *, const char *)" (declared at line 52 of "../../../client/src/unifycr-stdio.h")
UNIFYCR_DEF(fopen, FILE, (const char *path, const char *mode));
```
These errors appear to have occurred for two reasons:

1. A _wrap signature was on two lines and was truncated by the `grep`.

or

2. The `grep` appears to have altered the formatting of pointers, i.e.,

`FILE* UNIFYCR_WRAP(fopen)(const char *path, const char *mode)`
became
`FILE *UNIFYCR_WRAP(fopen)(const char *path, const char *mode)`.

This resulted in the `unifycr_translate.py` script interpreting them differently and thus,

`UNIFYCR_DEF(fopen, FILE *, (const char *path, const char *mode));`
became
`UNIFYCR_DEF(fopen, FILE, (const char *path, const char *mode));`.

To fix this (and the issues in step 2 of reproducing the problem), two potential options could be to write a more complicated `grep` and/or to update the `unifycr_translate.py` script to accommodate for these cases.

Note: This might change significantly when we switch to the latest version of GOTCHA (#151).

Note: This issue involves the same topic as enhancement #70.

Start with client/check_fns/README.md and unifycr_translate.py, then inspect the UNIFYCR_WRAP declarations in client/src/*.c and the generated client/src/gotcha_map_unifycr_list.h. Reproduce the grep and translation steps, checking the multiline signatures and pointer formatting described in the issue. Done means the documented generation process produces a header that builds successfully.

Written by the indexing model from the issue text.