Properly support syscalls in filter conditions (#352)

* Properly support syscalls in filter conditions

Syscalls have their own numbers but they weren't really handled within
falco.  This meant that there wasn't a way to handle filters with
evt.type=xxx clauses where xxx was a value that didn't have a
corresponding event entry (like "madvise", for examples), or where a
syscall like open could also be done indirectly via syscall(__NR_open,
...).

First, add a new top-level global syscalls that maps from a string like
"madvise" to all the syscall nums for that id, just as we do for event
names/numbers.

In the compiler, when traversing the AST for evt.type=XXX or evt.type in
(XXX, ...) clauses, also try to match XXX against the global syscalls
table, and return any ids in a standalone table.

Also throw an error if an XXX doesn't match any event name or syscall name.

The syscall numbers are passed as an argument to sinsp_evttype_filter so
it can preindex the filters by syscall number.

This depends on https://github.com/draios/sysdig/pull/1100

* Add unit test for syscall support

This does a madvise, which doesn't have a ppm event type, both directly
and indirectly via syscall(__NR_madvise, ...), as well as an open
directly + indirectly. The corresponding rules file matches on madvise
and open.

The test ensures that both opens and both madvises are detected.

test/rules/syscalls.yaml

@@ -0,0 +1,11 @@
+- rule: detect_madvise
+  desc: Detect any call to madvise
+  condition: evt.type=madvise and evt.dir=<
+  output: A madvise syscall was seen (command=%proc.cmdline evt=%evt.type)
+  priority: INFO
+
+- rule: detect_open
+  desc: Detect any call to open
+  condition: evt.type=open and evt.dir=< and fd.name=/dev/null
+  output: An open syscall was seen (command=%proc.cmdline evt=%evt.type file=%fd.name)
+  priority: INFO