identify missing calls from syscall() in libsr3shim

The initial implementation has been fairly thoroughly investigated on redhat 8. We initially were only expecting to have the syscall() implementation active on redhat 8 and ubuntu 18, where there is a known very common case of syscall usage by a very common package (file-utils... aka mv.)

* We expanded the solution to cover all possible calls to syscall() to prevent breakage of existing calls,
* We decided to have the syscall implementation active on all OS's, not just the ones mentioned above, as it is a general vulnerability where files could be written that we would miss.
* We now appreciate that newer kernels might have syscalls() we haven't implemented.
* If we build libsr3shim on a new system, it just has a canned syscall() implementation using the calls we have found on all previous ones.

There should be some kind of audit script to warn that there is a syscall defined on the current system that isn't covered by what we do in libsr3shim.

Start by inspecting libsr3shim's existing syscall handling and compare its covered calls with the syscall definitions available on the current system. The issue is complete when an audit script warns about defined syscalls that libsr3shim does not cover; no specific test or file path is provided.

Written by the indexing model from the issue text.