[MOOSE-421] FE: Support Core Icon Block / New Collection

[GeoffDusome]

What does this do/fix?

This pull request introduces significant changes to how icons are managed and selected in the project, migrating from a custom Icon Picker block to leveraging WordPress Core's Icon API and a new Modern Tribe icon collection. The update also removes the legacy Icon Picker block and its related infrastructure, updates the icon selection UI to use registered icons, and ensures compatibility with WordPress 7.1. Additionally, related dependencies and scripts are cleaned up, and styles are updated to match the new system.

Icon System Overhaul

• Removed the custom Tribe Icon Picker block and all associated scripts, components, and infrastructure, including related npm scripts and dependencies such as @svgr/cli and the icon-picker scripts from package.json. [1] [2] [3]
• Introduced support for the WordPress Core Icon block, and registered a new Modern Tribe icon collection using the Icons API. This includes the new Icons class for registering the collection and icons from SVG files, and hooks for initializing them. [1] [2] [3]

Icon Card & Inline Notice Block Updates

• Updated the Icon Card and Inline Notice blocks to pull icons from the registered icon collections. The default icon is now set using the new namespaced format (e.g., tribe/ai-sparkle), and the UI for icon selection in IconPicker.js has been rewritten to query registered icons and collections via the WordPress data API. [1] [2] [3] [4] [5] [6] [7] [8]

Code & Dependency Cleanup

• Removed legacy code and dependencies related to the old icon picker, including the icon-picker block, utility functions, and static icon lists. Updated relevant files to use the new icon system and removed unnecessary code. [1] [2] [3] [4] [5]

Styling Updates

• Added new editor styles for the shared icon picker component, ensuring the icon grid and selection UI are visually consistent with the new system. [1] [2]

Compatibility and Changelog

• Updated the minimum WordPress version to 7.1 in composer.json and added a changelog entry summarizing the migration to the new icon system and the removal of the legacy Icon Picker block. [1] [2]
• Updated PHPStan config to scan the new core icons file for compatibility with the latest WordPress Icons API.

These changes modernize the icon management system, improve maintainability, and align with current WordPress standards.

QA

Demo Environment:

• https://moose-dev-pr383.d1.moderntribe.qa/

Links to relevant issues

• Link to Issue

Screenshots/video:

• Link to Video

Pull request checklist

• I've added a changelog entry for these changes.
• I've linked to a relevant Jira issue.
• I've captured a screenshot or screencast of the changes and linked it above.

[GeoffDusome]

In talking with Spela, it seems like it's entirely possible we drop support for the core Icon block.

Design seems concerned that the experience for selecting an icon in the core Icon block vs how it has to be in the other instances is too confusing for editors and they should be made the same. Unfortunately, as I pointed out previously, the UI that's available in the core Icon block isn't available publicly and is a custom element within the core Icon block itself (https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/icon/components/custom-inserter/index.js). Of course, we could probably copy this implementation for our other use cases, but then that means we would need to add additional UI to the modal anyway for selecting size, color, etc. In that case, it's not the same UI and design would be unhappy as well.

Design additionally asked if it was possible for us to add the Icon block to the Icon Card or Inline Notice blocks - the answer to this was also no. Due to both of these blocks rendering server-side, there would be no ability for an editor to interact with the Icon block and it would only be for rendering which we're doing through PHP in the same way the Icon block does anyway.

While I see strength in using as many core features as we can - because we use icons in more places than just the "icon" block itself (core or custom), it makes sense for us to just use our custom approach and add to it if necessary on a project that might need additional features.

I do like the idea of replacing the current icon toggle in the Icon Card and Inline Notice blocks with a toolbar button to be more in line with the core Icon block, but that's a different conversation.

Anyone have any thoughts one way or another?