✨ Allow using a different Hex deployment

[fruno-bulax]

Closes #2817

This PR adds support for hex mirrors using the HEXPM_REPOSITORY_URL and HEXPM_API_URL environment variables.
If they are set, the respective base URLs will be used read operations like version resolution and fetching of packages. Note that these are only mirrors. Fully private repositories are not supported, so package publishing, updating, etc. disregards these variables.

I've manually tested these changes and made sure the only remaining calls to hexpm::Config::new happen in the publish, retire, etc. commands, but please let me know if you can think of a way to add automated tests.

Please also let me know of any places where I should document these environment variables!

(Lack of) Authentication

I initially wanted to implement authentication as well. This would have been easy before, but unfortunately the addition of mirrors complicated things quite a bit. As the repository and api mirror don't necessarily belong together, we would have to juggle up to 3 different authentication tokens ("main" hexpm instance for publishing operations, api mirror, and repository mirror.)

Therefore, I think we would need two additional configuration options to set authentication tokens. Something like HEXPM_REPOSITORY_MIRROR_API_KEY. On top of that, hexpm-rust requires you pass it two URLs but only a single token, so that would also need to be adapted.

[lpil]

This seems to have extended the scope- it permits the API endpoint to be configured too, which is unrelated to enabling the use of mirrors?

Is your goal here to enable alternative Hex deployments to be used? I think we would need to think more about how the configuration would work in this case.

[fruno-bulax]

It was my understanding that the scope grew to encompass alternative deployments of the API endpoint as well.
Mostly based on based on the comments following this one in the original issue.

Please let me know if I've misunderstood! I'm also not entirely convinced this is the best way to go forward — mostly due the authentication complications that I don't think can be adequately addressed with environment variables alone.

[lpil]

Ah! Sorry about that, I was not up to date with the issue.

I think this is useful still! @maennchen was just asking for the ability to use a different Hex instance, which this could be the foundation of. I'm not sure if this is enough yet though?