Improve container entrypoint options

[yanivagman]

The current entrypoint of Tracee's container does not expose the following features of tracee-ebpf (when not running tracee-ebpf as standalone with 'trace')

1. Capture forensics artifacts with the "--capture" flag
2. Filtering (in kernel) specific processes using the "--trace" flag
3. Outputing extra data, such as environment variables given for execve calls (which might also be useful for some rules) using the "--output" flag
4. Choosing the perf-buffer-size for tracee-ebpf, which might affect the number of dropped events when there are heavy loads.

We should improve the entrypoint to handle all of these options, and decide about the UI exposed by tracee container.

I suggest the following:

1. For easier handling of the flags, we should rewrite the entrypoint using go.
2. Expose "--capture" flag as is in tracee-ebpf
3. Expose "--perf-buffer-size" as is in tracee-ebpf
4. We should probably give the filtering capabilities of the "--trace" flag a new name under the container's entrypoint (as we use "trace" to start tracee-ebpf standalone) - ideas?
5. Extra data exposed by the "--output" flag should also have a new name under the container's entrypoint (as it is not "output" anymore, but extra event data given to tracee-rules.

[itaysk]

I always thought most of this should be solved when we have config from file #467
It's the most practical way to configure a complex application like tracee. wdyt?

[yanivagman]

It's a nice thing to have config from file, and I agree we should have one.
Yet, it doesn't come in place of letting the user choose how to start tracee without having one.
We should expose all of the features tracee has to offer from the command line, without the need to use a config file.
Then, if the user choose to, he can craft his own config file if he wishes to.