Missing suppressions for macOS Monterey (12.7.2, x86_64)

### Context

I am running valgrind on a 2016 Intel-based MacBook Pro running macOS 12.7.2. For context this is my first foray into C, gdb, and valgrind so my experience level is low. I recently installed valgrind-macos to be able to run it on my own machine instead of VMs (thank you for this excellent work - it was such a relief not to have to deal with the latency!). Valgrind seemed to install without error, and does identify issues with the code I've run through it, but it *also* identifies errors and leaks that don't seem to be associated with my programs (since they valgrind cleanly on linux). They seem to be related to dylib or dyld. I read through #11, #19, and #74 which all suggested this kind of issue should have been suppressed/corrected so I wonder if I'm missing a dependency or should install a different branch of valgrind-macos. (I followed the instructions in the README.)

I do note that 103 other errors are suppressed, but I'm wondering if there's a way to get the last few suppressed as well, or if I should simply ignore any errors related to dylib or dyld.

#### What went wrong?
Here is an example of the kinds of errors I see:

```
❯ valgrind ./sortLines input.txt ─╯
==78927== Memcheck, a memory error detector
==78927== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==78927== Using Valgrind-3.22.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==78927== Command: ./sortLines input.txt
==78927==
==78927== Invalid read of size 32
==78927== at 0x7FF81870BA21: ???
==78927== by 0x7FF8185C83FD: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185C690D: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185D6C45: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185F6058: printf (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x100003E2B: main (sortLines.c:72)
==78927== Address 0x10020bd60 is 0 bytes after a block of size 32 alloc'd
==78927== at 0x1001F2941: realloc (in /usr/local/Cellar/valgrind/HEAD-d14be1d/libexec/valgrind/vgpreload_memcheck-amd64-darwin.so)
==78927== by 0x7FF8185F54DB: sappend (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185F53D5: getdelim (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x100003C0B: readInput (sortLines.c:24)
==78927== by 0x100003DE5: main (sortLines.c:67)
==78927==
This is a sample test case
go!
==78927== Invalid read of size 32
==78927== at 0x7FF81870BA1D: ???
==78927== by 0x7FF8185C83FD: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185C690D: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185D6C45: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x7FF8185F6058: printf (in /usr/lib/system/libsystem_c.dylib)
==78927== by 0x100003E2B: main (sortLines.c:72)
==78927== Address 0x10020bdc0 is 16 bytes after a block of size 16 in arena "client"
==78927==
it checks your program's one argument behavior
==78927==
==78927== HEAP SUMMARY:
==78927== in use at exit: 12,475 bytes in 170 blocks
==78927== total heap usage: 182 allocs, 12 frees, 16,804 bytes allocated
==78927==
==78927== LEAK SUMMARY:
==78927== definitely lost: 4,160 bytes in 130 blocks
==78927== indirectly lost: 0 bytes in 0 blocks
==78927== possibly lost: 600 bytes in 3 blocks
==78927== still reachable: 7,715 bytes in 37 blocks
==78927== suppressed: 0 bytes in 0 blocks
==78927== Rerun with --leak-check=full to see details of leaked memory
==78927==
==78927== For lists of detected and suppressed errors, rerun with: -s
==78927== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 103 from 19)
```

If I run with `--leak-check=full` I get additional errors/leaks, but didn't want to spam the issue with a wall of text. If helpful, I can add.

I modified the following program, which was from an assignment in an online course. (Please forgive the messy code...still learning.)

```
#include
#include
#include

//This function is used to figure out the ordering
//of the strings in qsort. You do not need
//to modify it.
int stringOrder(const void * vp1, const void * vp2) {
const char * const * p1 = vp1;
const char * const * p2 = vp2;
return strcmp(*p1, *p2);
}
//This function will sort and print data (whose length is count).
void sortData(char ** data, size_t count) {
qsort(data, count, sizeof(char *), stringOrder);
}

char ** readInput(FILE * f, size_t * count) {
char ** lines = NULL;
char * curr = NULL;
size_t sz;
*count = 0;
while (getline(&curr, &sz, f) >= 0) {
lines = realloc(lines, (*count+1) * sizeof(*lines));
lines[*count] = curr;
curr = NULL;
(*count)++;
}
free(curr);
return lines;
}

void closeOnError(char * errMsg, int i, size_t * count) {
fprintf(stderr, errMsg, i);
free(count);
exit(EXIT_FAILURE);
}

int main(int argc, char ** argv) {
FILE * f = NULL;
char ** strings = NULL; // array to hold lines to sort
size_t * count = malloc(sizeof(*count));

if (argc == 1) {
// read from stdin
f = stdin;
// obtain list of strings and write into an array
strings = readInput(f, count);
// sort the lines of input
sortData(strings, *count);
// print the sorted strings and free memory for each string
for (int i = 0; i<*count; i++) {
printf("%s", strings[i]);
free(strings[i]);
}
// free memory for array of strings
free(strings);
} else {
// read from one or more input files
for (int i = 1; i < argc; i++) {
f = fopen(argv[i], "r");
if (f == NULL) {
closeOnError("Could not open input file %d!", i, count);
}
// obtain list of strings and write into an array
strings = readInput(f, count);
// sort the lines of input
sortData(strings, *count);
// print the sorted lines
for (int i = 0; i<*count; i++) {
printf("%s", (strings)[i]);
free(strings[i]);
}
// free memory
free(strings);
strings = NULL;
if (fclose(f) != 0) {
closeOnError("Could not close input file %d!", i, count);
}
}
}
free(count);
return EXIT_SUCCESS;
}
```
I compiled with `gcc -ggdb3 -Wall -Werror -std=gnu99 -pedantic -o sortLines sortLines.c`.

I ran `valgrind ./sortLines input.txt` where input.txt is:
```
This is a sample test case
it checks your program's one argument behavior
go!
```
#### What did you expect to happen?

I expected the following output, which is what I get when running through valgrind on a linux VM.
```
==270== Memcheck, a memory error detector
==270== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==270== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==270== Command: ./sortLines input.txt
==270==
This is a sample test case
go!
it checks your program's one argument behavior
==270==
==270== HEAP SUMMARY:
==270== in use at exit: 0 bytes in 0 blocks
==270== total heap usage: 11 allocs, 11 frees, 10,224 bytes allocated
==270==
==270== All heap blocks were freed -- no leaks are possible
==270==
==270== For lists of detected and suppressed errors, rerun with: -s
==270== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```

### Information

* macOS architecture (`uname -m`): x86_64
* macOS version (`sw_vers`): 12.7.2
* Xcode version (`xcrun --sdk macosx --show-sdk-version`): 13.1

Start by reproducing `valgrind ./sortLines input.txt` on macOS 12.7.2 x86_64 with the reported Xcode SDK, then compare the dylib and dyld reports with issues #11, #19, and #74. Done means the legitimate system-library reports are suppressed while errors from the sample program remain visible, with the result checked using Valgrind's suppression summary.

Written by the indexing model from the issue text.