[feature] Allow for custom messaging or remove NPM specific messaging

[jdfm]

Some of the error messages for this plugin specifically mention npm commands (like, no-extraneous-dependencies) which can be problematic if the established package manager in the codebase isn't npm. When dealing with a codebase maintained by a single person this isn't really a problem as that person will just know that they are using a specific package manager, but, in a codebase with a lot of developers, even if we've documented that we're using something other than npm, it can be confusing for a tool that we use say that we should use npm to fix an issue with our dependencies.

It would be very useful to either not mention npm explicitly and instead word it in a way that helps people find a solution based on their current expectations, or allow consumers of this plugin to override these messages to explicitly mention how to solve an issue with a specific toolset they have available in the codebase.

Relevant issue from upstream for more context: import-js/eslint-plugin-import#2434

[JounQin]

We can actually detect it with process.env.npm_execpath.

[SukkaW]

https://www.npmjs.com/package/package-manager-detector

Widely used, battle-tested. I myself have been using this in some of my projects and it just works.

[JounQin]

We only need https://app.unpkg.com/package-manager-detector@1.3.0/files/dist/detect.mjs#L14-21

[SukkaW]

https://app.unpkg.com/package-manager-detector@1.3.0/files/dist/detect.mjs#L14-21

Well, what happens if someone uses npm in a yarn/pnpm project? npm is the only package manager that doesn't respect the packageManager field in the package.json and will not early bail out.

[JounQin]

Well, what happens if someone uses npm in a yarn/pnpm project?

First, the message reported here is just a tiny improvement which doesn't deserve a 22KB dependency, and not to mention that it's ESM only.

And that's the user's fault to do like that, not the responsibility on our side.