Complete the plugin settings removal after the feat/plugin-feature merge

The merge kept this branch's PluginConfig design, which deletes
PluginDescriptor::settings, get_plugin_settings() and ctx.params, but left
references to them behind: the slic3rutils target did not build, and the
bindings test still asserted the removed ctx.params attribute.

Port the two settings tests onto PluginConfig instead of dropping them. They
guard a field bug where a cloud-metadata refresh wiped a plugin's settings and
it silently ran on its own defaults, so the equivalent properties are still
worth pinning: that a stored config survives the refresh, and that an edited
config reaches the plugin through a real dispatch.

Also defer PluginsConfigDialog's web commands off the webview script-message
callback, as PluginsDialog already does. Its remove_preset_override handler put
a modal wxMessageBox on that stack, which is the GTK crash class fixed in
b779a7bfed/f2ccbfc8b5 for the sibling dialog.

src/slic3r/GUI/PluginsDialog.cpp

@@ -483,8 +483,9 @@ void PluginsDialog::on_script_message(const nlohmann::json& payload)
     // Defer command handling out of the webview script-message callback: GTK and macOS
     // deliver it synchronously inside the native webview callback (see ui_create_window
     // in PluginHostUi.cpp), and window work on that stack is the crash class fixed in
-    // b779a7bfed/f2ccbfc8b5. Deferring at this single entry point keeps every command
-    // handler, current and future, off that stack by construction.
+    // b779a7bfed/f2ccbfc8b5. Deferring here keeps every command handler in THIS dialog off
+    // that stack; it is not a guarantee for other WebViewHostDialog subclasses, which each
+    // have to defer for themselves (PluginsConfigDialog does; others still do not).
     wxGetApp().CallAfter([this, alive = m_alive, payload]() {
         if (alive->load(std::memory_order_acquire))
             handle_web_command(payload);