Maven scopes - additional "AND" filter logic

[jssblck]

Overview

Updates the Maven scope filtering functionality so that users can specify "AND" relationships for excluding dependencies.

The existing functionality is as follows:

When a dependency is multi-scope (i.e. [compile, runtime]), by default if ANY of the scopes are contained in scope-exclude it will be excluded from the scan results:

version: 3

maven:
  scope-exclude: # Excludes dependencies that contain any of 'provided', 'system', or 'test' scopes.
    - provided
    - system
    - test

For example, using the above setting:

Dependency { name: "A", scopes: [ "compile" ]}           <- reported, because it doesn't match any excluded scope.
Dependency { name: "B", scopes: [ "test" ]}              <- not reported, because the scope "test" is excluded.
Dependency { name: "C", scopes: [ "compile", "system" ]} <- not reported, because the scope "system" is excluded.

The new functionality added is as follows:

For more control, the items provided to scope-exclude can be arrays; when this is done it only filters the dependency if ALL of the scopes in that item are contained in the dependency.

version: 3

maven:
  scope-exclude: # Excludes dependencies that contain the 'system' scope, or if they include both 'provided' and 'test' scopes.
    - [provided, test]
    - system

For example, using the above setting:

Dependency { name: "A", scopes: [ "compile" ]}                     <- reported, because it doesn't have any excluded scope.
Dependency { name: "B", scopes: [ "test" ]}                        <- reported, because it doesn't have "provided" scope.
Dependency { name: "C", scopes: [ "provided", "test", "compile" ]} <- not reported, because it has both "test" and "provided" scopes.
Dependency { name: "B", scopes: [ "system" ]}                      <- not reported, because it has the "system" scope.

Rendered documentation here.

Acceptance criteria

Users are able to exclude scopes more granularly.

Testing plan

Relying on automated tests.

Risks

This further complicates the config file.

Metrics

None

References

Resolves: https://fossa.atlassian.net/browse/ANE-1724

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
• If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.