Add support for custom error response from external registries

[luisgcoding]

What was the end-user or developer problem that led to this PR?

When gem fetching fails with HTTP errors, RubyGems currently displays the reasonPhrase field (e.g., "Forbidden", "Bad Request") from the HTTP/1.1 standard. External registries have to tweak this reasonPhrase field in order to send custom error message to the client (e.g: informing that a component was blocked by an internal policy violation). This approach has one issue: HTTP/2 removed the reasonPhrase field entirely (RFC 7540), so users only see numeric status codes like "403" without any descriptive text when using HTTP version 2, making the current workaround ineffective.

What is your fix for the problem, implemented in this PR?

This PR adds a new custom HTTP header called X-Error-Message. When present, the value from this header will be included in the error message displayed in the client's CLI instead of the reasonPhrase field.

For servers that do not send this header, the code maintains full backwards compatibility by falling back to the
current behavior (displaying the reasonPhrase from HTTP/1.1 or just the status code for HTTP/2).

This approach is already used by other major package management clients such as the Hugging Face CLI.

Alternate solution

Another approach would be to add support for RFC9457 (Problem Details for HTTP APIs), where RubyGems could check if the Content-Type has the value application/problem+json then parse the RFC9457 problem details response and display the information in a human-readable format to the client. However, the custom header approach was chosen for its simplicity and lower implementation overhead for both gem servers and the client. This could be another solution and I would like to hear from the community what are the thoughts about it.
This alternate solution was implemented in Maven.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[hsbt]

I didn't know custom error response approach. I like X-Error-Message header because it's simple with the current implementation of RubyGems.

We can re-consider that with application/problem+json content-type if we need to more extra support.