Support for Gradle dependency constraints in security scan

Currently gradle dependency constraints seems to be ignored by jf scan.

This means if we fix transitive dependency issues by defining relevant dependency constraints, the security scan continues to fail.
Honoring the dependency constraints would make the security scan much more convinient for our developers using gradle.

Describe alternatives you've considered
Instead of using dependency constraints it is currently only possible to overwrite versions of transient dependencies with direct dependencies. This is a bad solution as it creates a lot of direct dependencies which will never be directly used by the current application. Lateron it is hard to find which of those dependencies could be removed because they are obsolete.

Good Example

implementation 'com.jayway.jsonpath:json-path:2.7.0'
constraints {
	implementation('net.minidev:json-smart:2.4.11') {
		because 'previous versions have a security issue'
	}
}

Bad Alternative

implementation ('net.minidev:json-smart') {
	version {
		strictly '2.4.11'
	}
}

No implementation files, tests, or entry points are named in the issue. Start by locating the Gradle dependency parsing and security-scan resolution paths, then add coverage for the shown dependency-constraint example; done means constrained transitive versions are honored and the scan no longer reports vulnerabilities fixed by those constraints.