style(help): troubleshooting: added a tip about ensuring consistency between the commands Detect runs and the commands your build runs.
## Troubleshooting best practices
1. Run ${solution_name} with `--logging.level.com.synopsys.integration=DEBUG` (the default logging level, INFO, is insufficient for troubleshooting) and read through the entire log for clues.
+1. ${solution_name} typically runs package manager commands or build tool commands similar to commands used in your build.
+When run by ${solution_name}, those commands (as well as the environment
+in which they run) need to be consistent with your build, and it's important to verify that they are.
+For example, the Gradle detector defaults to running
+*./gradlew dependencies* if it finds the file ./gradlew. If your build runs a different Gradle command or wrapper
+(say, /usr/local/bin/gradle), use property
+*detect.gradle.path* to tell ${solution_name} to run the same Gradle command that your build runs.
+Check a DEBUG log for the package manager commands that ${solution_name} is running, and compare
+them to the commands your build runs.
1. For more troubleshooting information: Run ${solution_name} with `--detect.diagnostic=true`. This will generate a diagnostic zip that contains many useful intermediate files and logs, including the generated BDIO (.jsonld) files and ${blackduck_signature_scanner_name} logs.
1. For even more troubleshooting information: Run ${solution_name} with `--detect.diagnostic.extended=true`. This will generate an extended diagnostic zip that will also include lock files and build artifacts when appropriate.
1. See if you can reproduce the problem using the latest version of ${solution_name} with the latest version of ${blackduck_product_name}. If not, the problem may be either fixed, or due to incompatible ${solution_name} / ${blackduck_product_name} versions.
