Allow nested configs to specify parent/child configs.

New Issue Checklist

• [ yes] Updated SwiftLint to the latest version
• [yes] I searched for existing GitHub issues

Request

I'd like to propose allowing nested configs to specify a child_config. The current documentation states that:

Also, parent_config / child_config specifications of nested configurations are getting ignored because there's no sense to that.

However, lets take the following project structure:

ProjectRoot
       | - .swiftlint.yml // the main config with project wide rules
       | - DirA
       |      |- Sources
       |               |- //...
       |
       |      |- Tests
       |               |- .swiftlint.yml // nested config with specific rules for this folder
       |
       | - DirB
       |      |- Sources
       |               |- //...
       |
       |      |- Tests
       |               |- .swiftlint.yml // nested config with specific rules for this folder
       |
       | - DirC
       |      |- Sources
       |               |- //...
       |
       |      |- Tests
       |               |- .swiftlint.yml // nested config with specific rules for this folder
       |  
       | // Rest of the dir structure where I want just the base rules

This works great and allows me to refine the rules for the Tests Dirs A, B and C. However, let us say that I wanted to apply the exact same refinements to the Test folders on each of the 3 dirs. Right now I would be forced to copy_paste and maintain 3 different refinement files, which is quite unwieldy and bound to run out of sync.

However, if I could simply define the nested files as having a child_config pointing to a .swiftlint_test_refinements.yml then I could use that file as the single source of truth to maintain these refinements.

Another option would be to allow the nested configs to have a parent_config. swiftlint would generate the final rules for the Dir structure by using the project's config as the base, followed by any refinements from the nested config's parent_config, followed by the nested config's own refinements. I believe this would be more robust but probably harder to implement....

I believe this use case to be fairly common for mono-repo projects that have various libraries in the same project. Does the functionality seem sensible to the maintainers? If not, could you provide some guidance as to how I could achieve this with the existing rules?

Thank you for all the awesome work you folks have been doing so far!