Closes #25204

PR summary

This feels a bit more "workaround" than I'd really like, but it seems to work.

• Pyparsing warns when you try to name a forward reference before it is defined
  • As far as I can tell, it actually does work currently, but discussion on Adding a setResultsName() breaks grammar? pyparsing/pyparsing#95
    leads me to believe that we are relying on something that could change
  • When names are given, a copy is produced, and thus in theory the forward references won't get their definitions
    • In practice, they appear to
  • There is a warning which is disabled by default for this behavior.
    • Enabled with python -Wdefault, but not enabled in our test suite
  • The solution I came up with was to wrap it in another layer of forward reference
    • This feels like a hack, but the reference the outer forward holds gets filled out and a copy to that reference is transmitted to the copies.
  • I also considered
    • defining early
      • Can't do completely due to cycles, redefining is possible, but likely to be more fragile
    • Supressing warnings
      • Works for now, but seems not by design
    • Removing names
      • Would require (at least) more extensive code changes, as many test failures result.
    • Not using a Forward
      • Was unable to find something that did not obstruct values used by parsing functions (tried e.g. Group, + Empty(), etc)

The _fontconfig_pattern.py is a compatibility change adding a Group which was suggested by a similar warning.

PR checklist

• "closes #0000" is in the body of the PR description to link the related issue
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines