Add extension point for custom stored Font Awesome icons

[SoftCreatR]

Current State

WoltLab Suite 6.2 icon fields and rendering are effectively limited to native Font Awesome icon strings in the name;forceSolid format.

This means that packages can replace or extend the icon picker UI, but selected values cannot be accepted globally unless they still look like native WSC icon strings. In practice, this blocks package-safe integrations for icons that need additional identity data, for example:

• bundled brand SVG icons,
• externally provided icon packs,
• icons that are not part of WSC's native Font Awesome metadata,
• descriptors that need package-specific rendering.

Without a core extension point, third-party packages must either integrate with each consuming form individually or avoid storing extended icon values.

Proposed State

This PR adds a small extension point around stored icon resolution:

• FontAwesomeIcon::isValidString() first accepts native values as before.
• If a value is not a valid native icon string, WSC fires wcf\event\style\StoredIconResolving.
• A package may resolve the stored value to an IFontAwesomeIcon.
• FontAwesomeIcon::fromString() preserves the original stored string and delegates rendering to the resolved icon.
• Native icon behavior remains unchanged.

The Font Awesome picker callback is also extended in a backwards-compatible way:

(icon: string, forceSolid: boolean, value?: string, previewHtml?: string) => void

Existing picker consumers can continue using only icon and forceSolid. Replacement picker implementations can optionally provide:

• an explicit stored value,
• trusted preview HTML for non-native icon previews.

IconFormField and trophy badge previews now use these optional values when present, while retaining the native preview path for normal icons.

Why Accept This?

This gives WSC a narrow, package-safe extension point instead of forcing packages to patch core files or duplicate integrations for every icon field.

Benefits:

• Preserves existing native Font Awesome behavior.
• Enables package-safe support for additional icon sources.
• Allows existing core fields using IconFormField to accept custom stored icons without package-specific field forks.
• Keeps the rendering contract aligned with WSC's existing IFontAwesomeIcon abstraction.
• Avoids hardcoding third-party icon logic into WSC.
• Keeps the implementation small and opt-in: nothing changes unless a package listens to StoredIconResolving.

Downsides

• FontAwesomeIcon::isValidString() and fromString() now may fire an event for values that are not valid native icon strings.
• StoredIconResolving becomes a public extension point and therefore should be treated as API once released.
• previewHtml is trusted HTML supplied by the picker implementation. This is useful for SVG/custom previews, but the contract should make clear that extensions must not pass unsanitized user input.

Risks For WSC 6.2

The behavioral risk is low because native icon strings still take the same path as before. Existing callers and picker callbacks remain compatible.

The main 6.2 risk is API commitment: adding StoredIconResolving in a patch release means third-party packages may depend on it immediately. If the event shape should change, that is easier before release than after.

Waiting for 6.3 would reduce that API commitment risk, but it would leave 6.2 without a package-safe way to integrate extended icon sources. For installations already using WSC 6.2, packages would still need brittle field-specific workarounds or core patches.

Compatibility

This is intended to be backwards-compatible:

• existing native icon values still validate and render as before,
• existing picker callbacks still work,
• existing FontAwesomeIcon::fromString() consumers can render resolved custom icons without code changes,
• packages that do not listen to StoredIconResolving are unaffected.