Resolve resource domains from bracketed folder names

[Eldrinn-Elantey]

Load folders are named "[]" for readability, but the game asks for resources by the bare mod domain (ResourceLocation("gregtech", ...)), not by that display name.

The old .lang loading path happened to work anyway because Minecraft scans getResourceDomains() and tries each reported name as if it were a real domain, so the bracketed string round-tripped by accident. Any resource requested directly by its real domain (textures, models, or GregTech's new markdown tooltip files) never matched, since getResourcePath() resolved straight off the raw domain string.

Builds a domain -> folder map once (extracting the domain out of the brackets), rebuilt on every getResourceDomains() call since Minecraft calls that on every resource manager reload. getResourcePath() now resolves through that map, falling back to the old direct behavior if a domain has no matching folder.

[github-actions]

#28

[Eldrinn-Elantey]

Wrong approach, per glowblueman/attempt0's feedback in Discord: the bracketed folder names are load-bearing, not decorative. Minecraft merges .lang translations by iterating getResourceDomains() and loading each reported name's lang file separately, which is how a mod's own folder and an addon's separate contribution to the same real domain both get merged today. Reporting the extracted domain instead of the bracket name (as this PR did) collapses multiple contributing folders down to one reported domain, so only one of them would ever get resolved, silently dropping the other's translations.

The actual fix belongs in GTNH-Translations, scoped to the new markdown tooltip delivery path only, not the shared .lang mechanism this PR touched.