Bindings for app config path

[jw3]

Provide path to the app config through bindings

The Python side may need access to the configuration file, and while there is no need to provide fine grained config modeling in the bindings, having single authoritative path is useful.

This adds a single function config_file_path that provides the path to the application config as a string.

This also changes the config file name from fapolicy-analyzer.toml to config.toml. The file is already namespaced by the config dir, there is no need to duplicate it in the filename. This improves the readability of documentation and other discussions.

Closes #786

[jw3]

UI and backend sections can exist in the same file.

The backend will not add the ui section to the file upon creation, so the UI needs to plan for missing entries and provide a reasonable default.

Otherwise we will continue on with something like this

[ui]
initial_view = 'rules'

[system]
rules_file_path = '/etc/fapolicyd/rules.d'
trust_lmdb_path = '/var/lib/fapolicyd'
system_trust_path = '/var/lib/rpm'
trust_dir_path = '/etc/fapolicyd/trust.d'
trust_file_path = '/etc/fapolicyd/fapolicyd.trust'
syslog_file_path = '/var/log/messages'

[application]
data_dir = '/home/foo/.local/share/fapolicy-analyzer'

[jw3]

The UI can use the python toml package, it is in epel 8.

We can deal with a contract for writing when we have UI for config. I dont think it will be too complicated, something along the lines of

1. UI can write and apply its config on-demand
2. Changes to the backend config will always require a restart

Something like that anyhow.

[jw3]

This might be the first example for good ol #5

Should do more of this...