Add support for custom message headers from external registries

[luisgcoding]

Summary

This PR adds support for extracting custom error messages from the X-Error-Message HTTP header in network error responses, providing users with more detailed and actionable error information from package registries.

Problem

Currently, pip relies on the standard HTTP/1.1 reasonPhrase field to provide error context to users when encountering client errors from package registries. However, HTTP/2 drops this reasonPhrase field, leaving only the status code available. This results in less informative error messages for users.

Solution

• Added _extract_custom_error_message() function to parse the X-Error-Message header from HTTP responses
• Modified raise_for_status() to utilize custom error messages for 4xx client errors when available
• Maintained backward compatibility by falling back to standard HTTP reason phrases when the header is missing or empty
• Implemented registry-agnostic approach that works with any server using the X-Error-Message header

Testing

Added comprehensive test coverage including:

• Successful extraction of custom error messages
• Fallback behavior when headers are missing, empty, or whitespace-only
• Integration with raise_for_status() for both success and fallback scenarios

[pfmoore]

For some context, see https://discuss.python.org/t/block-download-of-components-when-violating-policy/104021

My current impression of that discussion is that RFC 9457 is more likely to be the preferred solution. But either way, I think this is likely to be something that should be standardised via a PEP, as it will be important that all clients (pip, uv, etc) use the same mechanism.

[luisgcoding]

For some context, see https://discuss.python.org/t/block-download-of-components-when-violating-policy/104021

My current impression of that discussion is that RFC 9457 is more likely to be the preferred solution. But either way, I think this is likely to be something that should be standardised via a PEP, as it will be important that all clients (pip, uv, etc) use the same mechanism.

Thank you so much for the quick response.