Fix fingerprint generation and validation against .gitleaksignore files for detect no-git scans

[uandrei]

Description:

When the source parameter is set for detect --no-git scans, the fingerprint generated contains the full path of the files with findings, meaning that .gitleaksignore will require full paths as well for the comparison to work.

This is not useful when gitleaks is run on build agents where the path can change between scans.

To fix the issue, the DetectFiles function has been updated to use relative paths all the time. Since the function is only used in no-git scans there is no regression affecting other types of scans.

Considering the change, not sure whether the major version needs bumping, will leave that to the maintainer to decide.

This fixes #1287.

Checklist:

• Does your PR pass tests?
• Have you written new tests for your changes?
• Have you lint your code locally prior to submission?

[neilfenwick]

When considering the versioning aspect, it may be possible that any baselines that have been generated with --no-git before this PR are affected because those may have fingerprints with absolute paths? (not sure if that is a common use-case though)

This PR effectively changes to use relative paths for --no-git scans, whether the scan is invoked for the current directory or with the --source argument.

[uandrei]

@zricethezav any chance you can please provide some feedback on this PR?

[zricethezav]

On paternity leave, I will when I get back