[Fix] Rework Slipstream Plugin Framework

[dgrkotsonis]

Slipstream Plugins: migrate to static plugin loading, remove runtime management endpoints

Motivation

The original Slipstream Plugins implementation used from_config_files() which loaded plugins as .so/.dylib files at runtime via libloading and exposed REST endpoints to allow one to load and unload plugins dynamically while the node was running. We have since reevaluated this need, so this PR goes hand-in-hand with the corresponding snarkVM PR, which changes the plugin manager to now use static linking with inventory self-registration.

New plugin flow

Plugins self-register at link time via inventory::submit!. At startup, snarkOS reads each JSON5 config file specified in the startup command flags, extracts the name field, and looks up the corresponding PluginRegistration via inventory::iter. The plugin is instantiated via its factory function and initialized via on_load before consensus starts. Adding a new plugin just requires adding it as an optional dependency under the slipstream-plugins feature in node/Cargo.toml.

Changes

• Plugin initialization (node/src/client/mod.rs, node/src/validator/mod.rs): replaced SlipstreamPluginManager::from_config_files() with a per-config loop that reads each JSON5 file, looks up the plugin by name via inventory::iter::(), and calls manager.register().
• REST API (node/rest/src/lib.rs, node/rest/src/routes.rs): removed POST /slipstream/plugins (load) and DELETE
  /slipstream/plugins/{name} (unload) endpoints and their handlers. GET /slipstream/plugins (list) remains. DELETE removed from CORS allowed methods (not used for anything else)
• node/Cargo.toml: slipstream-plugins feature now pulls in dep:slipstream-plugin-postgres, dep:json5, and dep:inventory. Plugin config files no longer require a libpath field.
• Updated plugin docs to reflect the new behavior

[dgrkotsonis]

TODO: Remove