Refactor ServerJars caching and move to api.serverjars.com

What does this MR do and why?

This Merge Request resolves issues faced from the unexpected ServerJars infrastructure outage.

Due to unforeseen circumstances the old build system and infrastructure (serverjars.com/api/) that Songoda previously provided is no longer accessible, so they've had to fast track their migration to their new system/infra (api.serverjars.com/api/)

Previously we would have had a grace period of 9 months to move Crafty over to the new infrastructure. But due to this outage we're having to get this set up and running quicker than expected, with there being certain differences from the previous implementation.

• The generic fetchTypes route is no longer present, The resulting as in to having to hard code the types to be able to retrieve the individual jar projects and versions.
• We now have a more sensible health check API route available that we can use, Instead of just requesting the fetchTypes route.
• Due to this unexpected outage, Songoda haven't had the chance to get this fully set up and stable. There are certain jar projects that are missing, such as some of the proxies and Spigot & Bukkit. We should expect to see these returning soon.
• The number of version responses is also less as well, Looking to be pinned at 5 max, Which aligns with the old documentation. But previously requesting these same endpoints used to give all versions instead of the default of five. I've tried to follow in the previous documentation and add additional path components to the route, But no luck. It will do for now though. ?max= parameter is now supplied where we now request the same number of versions we previously requested.

During the adjustments to get this running I also took advantage of this time to refactor the way we process and manage cache our cache, This rough refactor can still be improved upon, But it has tidied up the code significantly, making it easily readable/make sense, As well as reducing repeated code.

Screenshots or screen recordings

How to set up and validate locally

Deploy branch and try to refresh the cache on the create a server page.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• Have you checked this doesn't interfere/conflict/duplicate someone elses work?
• Have you fully tested your changes?
• Have you resolved any lint issues?
• Have you assigned a reviewer?
• Have you applied correct labels?