Provide a better way to let the user understand that setting options via IPC will make subsequent config file changes ineffective

[killown]

Describe the bug

    this->plugins_opt.set_callback([=] ()
    {
        /* reload when config reload has finished */
        idle_reload_plugins.run_once([&] () { reload_dynamic_plugins(); });
    });

Plugin reload/enable/disable will stop working after using set_option_values.

To Reproduce
Steps to reproduce the behavior:

def verify_required_wayfire_plugins():
    required_plugins = {
        "stipc",
        "ipc",
        "ipc-rules",
        "resize",
        "window-rules",
        "wsets",
        "session-lock",
        "wm-actions",
        "move",
        "vswitch",
        "grid",
        "place",
        "scale",
    }

    enabled_plugins = sock.get_option_value("core/plugins")["value"].split()

    for plugin_name in required_plugins:
        if plugin_name not in enabled_plugins:
            enabled_plugins.append(plugin_name)

    sock.set_option_values({"core/plugins": " ".join(enabled_plugins)})

verify_required_wayfire_plugins()

disable or enable a plugin in wayfire.ini

Expected behavior
plugin-loader should at least LOGE the reason why the plugins can't reload/enable/disable.

Suggestion
reload_config_signal somewhere in set_config_options will set a callback LOGI with the options that can't be modified by wayfire.ini

Why consider the Suggestion
It took me a while to find the issue, others might face the same problem without knowing the cause, some others could set random plugins options and complain later why these options is not changing through wayfire.ini.

[ammen99]

Looking at your PR #2708, I am thinking, maybe we can add an std::set of options for which we have emitted a warning? The idea is that once we emit the warning, we don't want to spam it again. So you can get a warning that an option has been overridden by IPC just once for each option at most.

Maybe we should even limit it to just a few warnings and say after 5-10 warnings warn that further warnings of this type will be suppressed?

[killown]

Looking at your PR #2708, I am thinking, maybe we can add an std::set of options for which we have emitted a warning? The idea is that once we emit the warning, we don't want to spam it again. So you can get a warning that an option has been overridden by IPC just once for each option at most.

Maybe we should even limit it to just a few warnings and say after 5-10 warnings warn that further warnings of this type will be suppressed?

#2714 using your suggestion with warnings limit and removed json data from logw looks ok