Drop is_plugin_active() guard in favor of per-function PMPro checks

[dparker1005]

Summary

Fixes #68 — the top-of-file is_plugin_active( 'paid-memberships-pro/paid-memberships-pro.php' ) early return failed when PMPro was installed under a non-standard folder name (e.g. release-candidate zips like paid-memberships-pro-rc1) and could fatal on frontend requests since is_plugin_active() lives in wp-admin/includes/plugin.php.

Replaces it with narrow function_exists() checks at each entry point that actually depends on PMPro:

• API loader registration — gated on pmpro_getOption() so the /toolkit/v1/* REST endpoints (whose handlers call pmpro_loadTemplate / pmpro_getLevel / pmpro_changeMembershipLevel / use PMPRO_DIR) are not registered when PMPro is not loaded.
• WP-CLI commands registration — same gate, so toolkit CLI commands (which load adminpages/scripts.php referencing $wpdb->pmpro_* and calling pmpro_changeMembershipLevel etc.) are not registered.
• pmprodev_process_migration_export() — gated on pmpro_getAllLevels() since PMProDev_Migration_Assistant::export() calls it.
• pmprodev_settings_page() — gated on pmpro_getParam() since adminpages/toolkit.php uses PMPRO_DIR and pmpro_getParam at parse time.

Other handlers do not need guards:

• pmprodev_checkout_debug_email already self-guards with function_exists( 'pmpro_is_checkout' ).
• pmprodev_gateway_debug_setup is already defensive with class_exists checks and harmless define() / remove_action() calls.
• pmprodev_admin_menu / pmprodev_admin_menu_bar silently no-op when their PMPro parent menu does not exist.
• The rest (pmprodev_init_options, pmprodev_redirect_emails, pmpro_toolkit_load_textdomain, pmprodev_plugin_row_meta, pmprodev_enqueue_scripts, pmprodev_enqueue_admin_scripts, pmprodev_create_button) are either purely toolkit-internal or only fire via PMPro hooks.

Test plan

• Install Toolkit with PMPro active under a non-standard folder name (e.g. paid-memberships-pro-rc1) — Toolkit features (settings page, debug emails, migration assistant) should all work.
• Install Toolkit without PMPro active — no fatal errors on frontend, admin, REST, or WP-CLI.
• With Toolkit performance endpoints enabled, deactivate PMPro — /wp-json/toolkit/v1/* should 404 instead of fataling.
• With Toolkit CLI commands enabled, deactivate PMPro — wp pmpro-toolkit <cmd> should report "Command not found" instead of fataling.
• Settings page (?page=pmpro-toolkit) loads cleanly under all combinations.
• Migration export still works under normal install.

🤖 Generated with Claude Code