Support for paths to resources on .sonarwhalrc

[sarvaje]

Original issue at the end.

On top of using package names, we should allow paths.

The scenarios that this unlocks are:

• Shared configurations in the same project There are some rules that apply to all moments of the development process, but some others that are only valid when the site is in staging or in production. For example: I could test my website locally, but I'm probably not going to compress my assets using brotli all the time. This way we can have a common file that we can extend from and have those configurations as part of the project:

{
  "extends": "./common/.sonarwhalrc",
  "connector": "local"
}

• Custom resources for the project Having to create a package for a custom rule/parser is some overhead that not everybody is willing to do (and TBH, not worth it if it is very specific). This way there's no need to publish a package to create it (we might want to improve the wizard and just create a single file with no testing files for this scenario?):

{
  ...
  "rules": {
    "./rules/my-custom-rule.js": "error"
  }
}

---

Steps to reproduce:

1. Go to rule-no-vulnerable-javascript-libraries
2. Run npm install
3. Run npm test

[sarvaje]

I've been talking with @molant and the idea is support not only id for resources, but also paths. This should avoid this problem and allow more flexibility to the configuration.

[alrra]

Done in 1e2e54f.