Add wildcard forced hosts (fix #1587)

[lllincoln]

I added wildcard support to [forced-hosts], resolving #1587. Unit tests pass and checkstyle passes and I've tested this against my own running proxy. I'd appreciate feedback or additional testing if needed, especially from those on #1587 who submitted the issue.

What this does

Consider the example from #1587

[forced-hosts]
# Soul Realms
"play.soulrealms.net" = [ "soulrealms-smp-1" ]
"yt.soulrealms.net"   = [ "soulrealms-smp-1" ]
"ip.soulrealms.net"   = [ "soulrealms-smp-1" ]
"soulrealms.net"      = [ "soulrealms-smp-1" ]

Now this can be changed to:

[forced-hosts]
# Soul Realms
"*.soulrealms.net" = [ "soulrealms-smp-1" ]
"soulrealms.net"   = [ "soulrealms-smp-1" ]

How matching works

I added AddressUtil.isHostMatchingPattern(pattern, host). Patterns are matched on each label where * matches exactly one label. To be matched, patterns must have the same number of labels as the host. Matching is case insensitive. For example:

• *.example.com matches a.example.com but not example.com (fewer labels) or b.a.example.com (more labels).
• b.*.example.com matches b.a.example.com

Matching order

In both ConnectedPlayer and ServerListPingHandler, forced-host lookup now follows a hierarchy where exact matches always win over wildcards, so adding a *.example.com entry won't change routing for any host you've already defined explicitly.

1. Exact match (unchanged).
2. Wildcard match (my addition).
3. Default (getAttemptConnectionOrder() in ServerListPingHandler, or an empty collection in ConnectedPlayer. this are both unchanged from what was before).

Tests

I added ForcedHostsTest covering isHostMatchingPattern cases for single and mid-pattern wildcards, label-count mismatches, and a non-matching domain.

Potential issue

If two different wildcard patterns could match the same host, the one chosen depends on config map iteration order. Would like feedback on what the behavior should be here

[WouterGritter]

This would most likely make #1730 redundant.

[lllincoln]

This would likely make #1730 redundant. However, this fix is more flexible because it adds pattern matching and this fix doesn't need a config migration. That said, #1730 does consider SRV records, which I didn't fully consider yet. I can integrate this though.