Legacy/BungeeGuard forwarding FML/FORGE hostname token fixes

[p0t4t0sandwich]

While working through implementing Legacy+BungeeGuard forwarding for ProxyCompatibleForge, I realized that #1176 never implemented a way for Velocity to forward the modern FORGE[#] hostname token when legacy forwarding types were in use.
Additionally, while testing I found that the existing token forwarding for 1.8 - 1.12.2 didn't work with BungeeGuard forwarding.

The latter was a simple one-line fix, but I'd like some feedback regarding forwarding the modern FORGE[#] token, or if there are any other sections that need a tidy.

Somewhat in-line with Waterfall's "forgeClient" and "extraData" properties, I've added a new "modernForgeClient" property to account for backend implementations that always associate "forgeClient" with the older FML token, or backend implementations built with respect to Waterfall assuming the forwarded token is in the form of FML[#]. Any implementation that appends the "extraData" verbatim to the hostname (and replaces \1 with \0) should continue to function as expected.

To note, I've explicitly strayed away from adding additional handling for FML2 and FML3 (Forge 1.13.2 - 1.20.1 and NeoForge 1.20.2), as in testing I found the resulting handshake errors from NeoForge 1.20.2 to be quite ambiguous, and would probably confuse users more than the current "vanilla <-> Neo/Forge" connection errors they would encounter.

Some notes regarding Neo/Forge markers:

• NeoForge 1.20.4-present: N/A
• Forge 1.20.2-present, Format: \0FORGE + NET_VERSION
• NeoForge 1.20.2, Format: \0FML + NET_VERSION, where NET_VERSION is only ever 3
• Forge 1.13.2 - 1.20.1, Format:\0FML + NET_VERSION
  • Forge 1.13.2 - 1.18.1: \0FML2
  • Forge 1.18.2 - 1.20.1: \0FML3
• Forge 1.8 - 1.12.2, Format: \0FML\0