Allow enabling/loading individual BPF programs

[Molter73]

With the growing number of BPF programs we are adding there is a real chance one of them will refuse to load on some kernel, completely stopping execution of fact, or cause some unintended interactions on certain workloads (performance issues, etc.). As such, it would be a nice implementation to have some configuration available that will allow us to toggle whether individual programs are loaded/attached.

[Molter73]

Will probably try to tackle this one after I wrap up some work I have pending. My current idea for this implementation is to add a new configuration value like:

struct BpfProgConfig {
    enabled: bool,
    loaded: bool,
}

With this type, enabled would essentially be a synonym of attaching the program to the corresponding hook. By default, both values would be set to true to keep compatibility with the current way fact operates. A missing configuration value should also be treated as true. The table of truth would expand to something like this:

enabled	loaded	description
true	true	program is loaded and attached (default)
false	true	program is loaded but not attached, will generate no events
true	false	invalid state, program cannot be attached if not loaded, issue a warning and operate as enabled=false
false	false	program is not loaded, will generate no events

An important distinction between enabled and loaded is that loading the programs only happens on startup and this behavior will be maintained, meaning that changing the value of a loaded program will require a restart. Enabling/disabling already loaded programs can be done on the fly.

In order to simplify maintenance of this configuration, the FactConfig/BpfConfig object can load them into a HashMap<String, BpfProgConfig>, which will allow newer hooks to directly support this configuration with no additional code being added.

Example of what the yaml configuration would look like:

bpf:
  programs:
    # Same as default configuration
    file_open:
      enabled: true
      loaded: true
    # Loaded in the kernel but not attached
    path_unlink:
      enabled: false
      loaded: true
    # Not loaded in the kernel
    path_chmod:
      enabled: false
      loaded: false
    # Invalid, will behave as the previous case
    path_chown:
      enabled: true
      loaded: false

As for implementing this as CLI arguments/env vars, due to its complex nature, we probably want this to be treated as a JSON encoded string, so we would have something like:

FACT_BPF_PROGRAMS='{"file_open":{"enabled":true,"loaded":true},"path_unlink":{"enabled":false}}'

JSON encoded strings in shell environments are not fun, but ATM I don't see a better solution.