This PR consists of a series of small improvements to SensitiveDataHeuristics.qll, intended to find more true and less false sources of sensitive data. One of these changes addresses a request from a user, the rest are motivated by issues we've spotted at various points in the past. None are expected to have a big impact by themselves (but 7 changes x 5 affected languages is quite a lot of surface area).

• more TPs: card.?no, api.?tok, security.?code patterns. We already had similar cases but no exact coverage for these.
• less FPS: wildcard_no is not card.?no; profile is not file; cauthor is not oauth.
• more TPs: the logic for identifying encrypted / encoded values (based on the variable name) was overly wide, excluding names such as security_code for containing code. It was also handling unencrypted incorrectly - while unencrypt was not matched due to the special case, the crypt substring was matched due to the entire unen part of the regex being optional. Copilot gets most of the credit for spotting this one.

Draft PR because I need to:

• check CI
• run and examine DCA (all languages)
  • check performance as well
• run and examine MRVA 100 runs
  • Rust --- we gain a few hundred pieces of sensitive data across the Rust MRVA-100, I looked at most of them and I’m very happy with what I saw.
  • Python --- we gain nearly five hundred pieces of sensitive data across the Python MRVA-100. I looked at a decent sample (> 40) and found mostly excellent additions, plus a few weak ones, and a few incorrectly labelled results lost. The rule for account matches a bit widely and we could potentially add a “not sensitive” rule for validator, if we see more of either of these cases.
• add change notes