Support distinct handling and configuration for DCHECK failures

[ArthurSonzogni]

Separates DCHECK failures from standard CHECK failures to enable granular severity assessment and issue tracking policies.

In Chromium, DCHECK failures often carry different security and priority implications than production CHECK failures. While they may not always be treated as immediate security vulnerabilities, they present information disclosure risks if filed publicly. Current logic groups them together, preventing distinct visibility rules.

Detailed changes:

• Stack Parsing: Updates stacktraces regex constants to explicitly distinguish "DCHECK failed" from "Check failed/NOTREACHED", assigning the distinct crash type DCHECK failure.
• Security Implications: Introduces the DCHECKS_HAVE_SECURITY_IMPLICATION environment variable to control whether DCHECKs are flagged as security issues per-fuzzer.
• Policy Engine: Refactors IssueTrackerPolicy to support recursive configuration application. This allows nested conditions (e.g., all -> non_security -> dcheck) to apply specific labels, access limits, or priority levels based on the intersection of crash traits. This decouple the configuration depth from the code, enabling arbitrary nesting or rules and simplifying the addition of future condition types.

Bug: https://issues.chromium.org/issues/406667202

[ArthurSonzogni]

Hey @letitz I would be happy to get some feedback about this patch? Does the allow Chrome to properly adjust visibility of dcheck failures according to you? (Via a new config and/or via the environment flag for specific fuzzers)

The review is a low priority. I can wait as long as needed.