[WIP] Standardize FontAwesome usage

[dannon]

Replace the string-based FontAwesome library approach with direct SVG icon imports for better tree-shaking and type safety.

• Better tree-shaking (only used icons get bundled)
• Type safety improvements
• Reduced global state pollution
• More explicit dependencies

Changes:

Removed library.add() calls: Eliminated all library.add() statements that were registering icons globally
Removed library imports: Removed import { library } from "@fortawesome/fontawesome-svg-core"
Updated icon usage patterns: Changed from string-based icon references to direct icon object references

Before:

  import { library } from "@fortawesome/fontawesome-svg-core";
  import { faCopy } from "@fortawesome/free-regular-svg-icons";
  library.add(faCopy);

  // Template usage:
  <FontAwesomeIcon icon="copy" />
  // or
  <FontAwesomeIcon :icon="['far', 'copy']" />

After:

  import { faCopy } from "@fortawesome/free-regular-svg-icons";

  // Template usage:
  <FontAwesomeIcon :icon="faCopy" />

The icon plugin/mixin are still up in the air. I could see pushing it all through a GIcon if we wanted, instead of FontAwesome directly, and can make that changes. This first standardization pass is important though, either way, just to get it all aligned.

[dannon]

There are a few remaining instances and some linting to fix, but I'll keep rebasing into this so we have a clear cutover changeset.

[ElectronicBlueberry]

With removing the library function, I would be in favor of also removing this file. I feel like it's an ambiguous abstraction, that makes it harder to trace the actual icon. But maybe there's an upside I'm missing

[dannon]

@ElectronicBlueberry That's what I was thinking, too, 👍

(mentioned above, the only question is on whether we want a GIcon or something as a compatibility interface between Galaxy and Icons in case we need/want to change down the road. But since we're locally importing a slew of direct SVGs from fontawesome anyway, I don't see a benefit here.)