Support rulesets at different levels in the project

[rob-baillie-ortoo]

Is your feature request related to a problem? Please describe.
With SFDX it's now possible to split your Salesforce code and config into different folders - to take a folder based modular approach.
This is useful when:

1. Splitting up legacy code from new code
2. Importing libraries / 3rd party code and keeping it distinct

When doing so, it's not unusual for the different sets of code to have different requirements of quality:

1. Legacy code may be held to a lower standard to new code
2. Imported libraries / frameworks may provide mechanisms that are mandatory when the library is used but not possible to be used within that framework
3. Libraries / Frameworks may come with their own standards for code and testing

At the moment it seems that the ruleset for a project is applied across the whole project, which means that code in these different levels are all held to the same level of quality and false positives are presented.

Describe the solution you'd like
It would be good if the extension could be configured to recognise rulesets defined at any level and then use that to check files at any point at or below that level.

This will allow:

1. Libraries to ship with a ruleset that is then enforced wherever that library is imported.
2. Code to be split into legacy and new and have different rulesets and therefore standards of quality applied to each part.

[ChuckJonas]

Definitely an interesting feature...

Unless this is something PMD supports natively, we'd need to do a recursive check of the project and then spin off a PMD process for each ruleset found.

It would require an overhaul to how we deal with specifying rulesets, but I think in a good way (moving away from vscode configurations and having it be "source driven")

[bobalicious]

We resolved this for 'submodules' by:

• Provide a pmd-ruleset at each level where we want the rules to be different (basically in the root of each submodule)
• In the higher level rulesets, define 'exclude-pattern' nodes that exclude the folders that contain overriding rulesets
• Specify all the pmd-rulesets in the VSCode workspace level config
• Commit the workspace level settings.json into version control

I have to admit, it's not ideal, but it seems to basically work for this limited use-case. Will update here if we find limitations that aren't ideal, or if we extend its usage.

I have to admit, I had assumed that you would spin off a pmd process for each defined ruleset in the configuration.