Improve shared sensitive data library handling of snake_case variable names

[geoffw0]

Improve the share sensitive data library handling of snake_case variable names. This is especially relevant for Rust, where snake case is encouraged and widely used, but the main change is in the shared SensitiveDataHeuristics.qll file and will affect (hopefully benefit) other languages as well. It's a simple change, but we need a fairly high level of confidence / agreement before merging this.

Testing:

• CI / tests passing (if you add up the sensitive data tests across all languages, coverage is really quite good)
• review differences in sensitive data identified
  • Rust, all DCA projects (by running rust/summary/sensitive-data) --- experiment, 389 new sensitive expressions, LGTM
  • Swift, MRVA top-100 projects (by running swift/summary/sensitive-expressions) --- no differences
• review differences in query results (DCA) --- all new results look at least as good as existing results
  • Javascript --- no new results
  • Python --- 1 new result; I believe this is logging "Updating pool config for auth key: {auth_key}" with a key (that might only be a public key), as part of some blockchain logic.
  • Ruby -- 8 new results; the first is hashing a secure random number session_id with MD5. The second is a user_id with SHA1. The rest appear to be variations on this theme.
  • Rust --- no new results (we haven't yet merged our first query that uses sensitive data!)
  • Swift --- no new results
• check performance
  • swift/summary/sensitive-expressions (locally) --- no significant differences
  • swift/cleartext-logging (locally) --- no significant differences
  • DCA analysis times, all languages --- 3% overall slowdown for Swift, which is well within normal wobble; negligible wobble for other languages.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again, by re-requesting a review.

[jketema]

LGTM

[geoffw0]

Thanks all, merging!