Is your feature request related to a problem? Please describe.
A whole heck of a lot of secrets require multiple credentials, e.g., AWS session tokens which require both a client id and PAT.

Describe the solution you'd like
A way to express multi component rules in the config.

Describe alternatives you've considered
#1812. This is fantastic effort but has a bidirectional reference problem - subRule and isSubRule is redundant and could get out of sync. Aesthetically, I prefer some of the options listed below more than the proposed solution in 1812.

Additional context
There are a couple ideas I've been gnawing on:

1. Groups:

# Regular rules remain unchanged
[[rules]]
id = "aws-access-key"
description = "AWS Access Key"
regex = '''(?:A3T[A-Z0-9]|AKIA|ASIA|ABIA|ACCA)[A-Z0-9]{16}'''
tags = ["key", "AWS"]

[[rules]]
id = "aws-secret-key"
description = "AWS Secret Key"
regex = '''(?i)aws_(.{0,20})?=?.[\'\"0-9a-zA-Z\/+]{40}'''
tags = ["key", "AWS"]

# New concept: credential groups
[[credential-groups]]
id = "aws-credentials"
description = "AWS Access Key and Secret Key pair"
# Rules that form this credential group
rules = ["aws-access-key", "aws-secret-key"]
# Maximum line distance between components
proximity = 5
# When true, individual findings still reported
report-individual = false

2. Primary Rule's [[rules.required]] (array of tables):

[[rules]]
id = "aws-secret-key"
# ...
[[rules.requires]]
id="aws-access-token"
distance=5 # unit defaults to "lines"

[[rules]]
id = "aws-access-token"
report=false
# ...

3. Primary Rule's [rules.required] (table):

[[rules]]
id = "aws-secret-key"
# ...
[rules.requires]
ids=["aws-access-token", "another-one"]
distance=5

[[rules]]
id = "aws-access-token"
report=false

[[rules]]
id = "another-one"
report=false
# ...

What is distance or proximity? If set it's a filter to make sure component rules are near each other. Typically (I have no evidence), multi-component secrets are near one another.

How the heck do we handle:

1. Reporting... I'm thinking a field like components or auxiliary-findings could be added to the primary finding.
2. Fingerprints?
3. Config extensions?
4. How do we handle cases where the distance/proximity is out of bounds from the data provided in the fragment?
5. How do we handle distance/proximity for git scans? Do we update the source to include context lines?

I'm leanin' toward number 2

cc @zricethezav