tainting: Introduce a special kind of sanitizer

[IagoAbal]

In PA-402 we made all sanitizers "not-conflicting" so that one could
declare $F(...) as a sanitizer without conflicting with sources and
sinks. That makes sense in that particular use case, but it partially
breaks our ability to simulate sanitizers by side effect. For example:

pattern-sanitizers:
  - patterns:
      - pattern-inside: |
          $JWT.verify($TOKEN, ...)
          ...
      - pattern: $TOKEN
pattern-sinks:
  - patterns:
      - pattern: $JWT.decode($TOKEN, ...)
      - pattern: $TOKEN
pattern-sources:
  - pattern: $TOKEN

no longer works on this example:

jwt.verify(token, key);
// ok: test
jwt.decode(token, true);

Since the second token is both matched by a sanitizer and a sink (and
a source), the sanitizer is now "disabled" due to the changes made by
0b35ab5 in connection with PA-402. This is not at all desirable, but
we still want the ability to declare $F(...) as a sanitizer. Then the
simplest solution seems to be to support two different kinds of
sanitizers.

Closes: PA-455
Changes: 0b35ab5 ("tainting: Filter out sanitizers that conflict with sources/sinks (#3958)")

test plan:
make test # tests included

PR checklist:

• Documentation is up-to-date
• Changelog is up-to-date
• Change has no security implications (otherwise, ping security team)

[linear]

PA-455 Re-think "sanitizers cannot conflict with sources/sinks"

Consider

rules:
  - id: test
    languages:
      - javascript
      - typescript
    message: Test
    mode: taint
    pattern-sanitizers:
      - patterns:
          - pattern-inside: |
              $JWT.verify($TOKEN, ...)
              ...
          - pattern: $TOKEN
    pattern-sinks:
      - patterns:
          - pattern: $JWT.decode($TOKEN, ...)
          - pattern: $TOKEN
    pattern-sources:
      - pattern: $TOKEN
    severity: WARNING

and

jwt.verify(token, key);
// ok: test
jwt.decode(token, true);

Here we get a match because token is already a source and a sink, so it cannot be a sanitizer... This makes more sense when we talk about $F(...) but here I'm not so sure this is intuitive.