Better NPM error messages

What does this MR do and why?

🔥 Problem

When an $ npm interacts with the GitLab NPM package registry, that interaction can fail and it's not always obvious why the interaction failed.

Example:

$ npm publish
npm notice 
npm notice 📦  splash@1.2.12
npm notice === Tarball Contents === 
npm notice 387B package.json
npm notice === Tarball Details === 
npm notice name:          splash                                  
npm notice version:       1.2.12                                  
npm notice filename:      splash-1.2.12.tgz                       
npm notice package size:  347 B                                   
npm notice unpacked size: 387 B                                   
npm notice shasum:        6234e94e9b989e30c646d64eed7aefa085585a24
npm notice integrity:     sha512-w4xEzqNehoCVN[...]cOzO4JUGNgOpA==
npm notice total files:   1                                       
npm notice 
npm notice Publishing to http://gdk.test:8000/api/v4/projects/343/packages/npm/ with tag latest and default access
npm ERR! code E403
npm ERR! 403 403 Forbidden - PUT http://gdk.test:8000/api/v4/projects/343/packages/npm/splash
npm ERR! 403 In most cases, you or one of your dependencies are requesting
npm ERR! 403 a package version that is forbidden by your security policy, or
npm ERR! 403 on a server you do not have access to.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/david/.npm/_logs/2023-02-06T14_01_29_568Z-debug-0.log

-> 403 Forbidden.

The lack of information creates this situation on users:

• Is it due to wrong credentials?
• Wrong config?
• Wrong URL?
• GitLab Project access levels?

This situation makes it hard for users and GitLab members to debug issues with the npm Registry.

🚒 Solution (introduced by this MR)

While investigating third party NPM registries behaviors, I noticed that they were able to provide custom error messages.

Upon investigation, $ npm will read the error field in the response json structure and output it.

Taking the example above and providing the error field:

$ npm publish
npm notice 
npm notice 📦  splash@1.2.12
npm notice === Tarball Contents === 
npm notice 387B package.json
npm notice === Tarball Details === 
npm notice name:          splash                                  
npm notice version:       1.2.12                                  
npm notice filename:      splash-1.2.12.tgz                       
npm notice package size:  347 B                                   
npm notice unpacked size: 387 B                                   
npm notice shasum:        6234e94e9b989e30c646d64eed7aefa085585a24
npm notice integrity:     sha512-w4xEzqNehoCVN[...]cOzO4JUGNgOpA==
npm notice total files:   1                                       
npm notice 
npm notice Publishing to http://gdk.test:8000/api/v4/projects/343/packages/npm/ with tag latest and default access
npm ERR! code E403
npm ERR! 403 403 Forbidden - PUT http://gdk.test:8000/api/v4/projects/343/packages/npm/splash - Package already exists.
npm ERR! 403 In most cases, you or one of your dependencies are requesting
npm ERR! 403 a package version that is forbidden by your security policy, or
npm ERR! 403 on a server you do not have access to.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/david/.npm/_logs/2023-02-06T14_01_14_610Z-debug-0.log

Notice the additional information provided by the logs:

npm ERR! 403 403 Forbidden - PUT http://gdk.test:8000/api/v4/projects/343/packages/npm/splash - Package already exists.

-> The Package already exists (duplicates are not allowed in the npm Registry).

How to set up and validate locally

1. Try to republish the same version of an already published npm package on your local instance of GitLab.
2. You should see the error now being returned in the logs:

npm ERR! 403 403 Forbidden - PUT http://gdk.test:8000/api/v4/projects/343/packages/npm/splash - Package already exists.

MR acceptance checklist

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

• I have evaluated the MR acceptance checklist for this MR.

Related to #390566 (closed)