Aarch64 build issues

I recently noticed the ARM CI for one of my projects that uses ISA-L was failing during build with
```
CC erasure_code/aarch64/libisal_la-gf_nvect_dot_prod_sve.lo
erasure_code/aarch64/gf_nvect_dot_prod_sve.c:33:10: fatal error: arm_sve.h: No such file or directory
33 | #include
| ^~~~~~~~~~~
```
I eventually figured out that `arm_sve.h` is provided by gcc and [seems to have been first included in 10.1](https://gcc.gnu.org/gcc-10/changes.html#aarch64); if nothing else, it seems we should update `README.md` which currently lists 4.7 as the minimum required version.

Looking at my CI, sure enough, it was using 9.4 -- the default provided by Ubuntu 20.04. OK, that's old enough to be out of standard support, fair enough. It's fairly easy for me to control base OS version (easier than controlling specific gcc version, anyway). When I moved to Ubuntu 22.04 (which *is* still in standard support, and provides gcc 11.4), building succeeds -- but running tests under valgrind (3.18.1) blows up the first time it tries to `dlopen` isa-l:
```
93 - {.with_args = test_create_and_destroy_backend}: isa_l_rs_vand (idx=0) ... --36727-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92

valgrind: m_debuginfo/readdwarf.c:2761 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

host stacktrace:
==36727== at 0x58040FEC: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x58041143: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580412AB: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580C1617: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580C17B3: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580C6DC3: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x5807A887: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x5806FA37: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x5809EB37: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580AAF43: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x5809AA63: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x5809636B: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580987BF: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0x580DEC8F: ??? (in /usr/libexec/valgrind/memcheck-arm64-linux)
==36727== by 0xFFFFFFFFFFFFFFFF: ???

sched status:
running_tid=1

Thread 1: status = VgTs_Runnable syscall 222 (lwpid 36727)
==36727== at 0x401D7AC: __mmap64 (/misc/../sysdeps/unix/sysv/linux/mmap64.c:58)
==36727== by 0x401D7AC: mmap (/misc/../sysdeps/unix/sysv/linux/mmap64.c:46)
==36727== by 0x40079CB: _dl_map_segments (/elf/./dl-map-segments.h:140)
==36727== by 0x40079CB: _dl_map_object_from_fd (/elf/./elf/dl-load.c:1258)
==36727== by 0x4008ACF: _dl_map_object (/elf/./elf/dl-load.c:2327)
==36727== by 0x400C727: dl_open_worker_begin (/elf/./elf/dl-open.c:534)
==36727== by 0x4A11FCB: _dl_catch_exception (/elf/./elf/dl-error-skeleton.c:208)
==36727== by 0x400BEF7: dl_open_worker (/elf/./elf/dl-open.c:782)
==36727== by 0x4A11FCB: _dl_catch_exception (/elf/./elf/dl-error-skeleton.c:208)
==36727== by 0x400C2FB: _dl_open (/elf/./elf/dl-open.c:883)
==36727== by 0x495C443: dlopen_doit (/dlfcn/./dlfcn/dlopen.c:56)
==36727== by 0x4A11FCB: _dl_catch_exception (/elf/./elf/dl-error-skeleton.c:208)
==36727== by 0x4A120A3: _dl_catch_error (/elf/./elf/dl-error-skeleton.c:227)
==36727== by 0x495BEF7: _dlerror_run (/dlfcn/./dlfcn/dlerror.c:138)
==36727== by 0x495C4E7: dlopen_implementation (/dlfcn/./dlfcn/dlopen.c:71)
==36727== by 0x495C4E7: dlopen@@GLIBC_2.34 (/dlfcn/./dlfcn/dlopen.c:81)
==36727== by 0x489260F: liberasurecode_backend_open (org/openstack/liberasurecode/src/erasurecode.c:138)
==36727== by 0x489260F: liberasurecode_instance_create (org/openstack/liberasurecode/src/erasurecode.c:243)
==36727== by 0x10CB1F: test_create_and_destroy_backend (org/openstack/liberasurecode/test/liberasurecode_test.c:541)
==36727== by 0x10C3EB: main (org/openstack/liberasurecode/test/liberasurecode_test.c:2392)
client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFF810
valgrind stack range: [0x1002CB8000 0x1002DB7FFF] top usage: 19584 of 1048576
```
Moving all the way to Ubuntu 24.04 (gcc 13.3, valgrind 3.22.0), everything works. It's not clear to me whether it was the newer gcc or the newer valgrind that fixed the `dlopen` issue...