Expose detector-specific false positive logic

[rosecodym]

Description:

This PR:

• Creates an optional interface that detectors can use to customize their false positive detection
• Implements this interface on detectors that have custom logic
• In most cases this "custom logic" is simply a no-op because the detector does not participate in false positive detection
• Eliminates inline (old-style) false positive exclusion in a few detectors that Move detectors.IsKnownFalsePositive from the detectors and into the engine #2643 missed

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[rosecodym]

This custom logic wasn't moved into a CustomFalsePositiveChecker implementation because secretMatch is no longer available by the time that runs. This type of change (which "narrows" false positive detection) was made for multiple other detectors in #2643 so I'm not worried about it.

[ahrav]

Neat!

[mcastorina]

Nit: If all parameters are ignored, you can omit _. You can even omit c in the pointer receiver.

func (*CustomRegexWebhook) IsFalsePositive(detectors.Result) bool

[mcastorina]

Did you consider creating a struct that implements this so it can be embedded into the Scanner struct?

// in detectors package
type SkipFalsePositiveCheck struct{}

func (SkipFalsePositiveCheck) IsFalsePositive(Result) bool {
    return false
}

// elsewhere

type Scanner struct {
     detectors.SkipFalsePositiveCheck
}

[rosecodym]

no, i didn't! does that save any implementation effort?

[mcastorina]

Marginally? imo it's a "nice-to-have" for a common scenario, especially for areas of the code that get a lot of outside contribution.