[K9VULN-2229] Various SARIF mod code cleanups

[jasonforal]

(For better organization, this PR is split off from one that implement SARIF artifacts).

What problem are you trying to solve?

We'll be adding the run/artifacts property from the SARIF spec in an upcoming PR.

While implementing that, I ran into some minor annoyances:

• Adding a new property to output broke unrelated tests because those tests hardcode the entire expected SARIF. Ideally, each unit test only targets a specific behavior.
• For each file, we currently have three different serialized forms (all opaquely using the String type).
  • The path as reported by the walkdir (which will be the OS-native form)
  • The unix path (i.e. on Windows systems, the path from above will be converted to unix format)
  • A percent-encoded path (e.g. converting [ to %5B)
    As-is, these transformations are performed by functions with vague names.

What is your solution?

• Narrow down each unit test to only test specific behavior.
• Rename functions to be more descriptive (and a small nit to reduce allocations)

Alternatives considered

What the reviewer should know

• A better solution for the path issue would be to newtype each of the 3 formats for paths so we can have compile-time safety. However, this is foregone to keep changes as minimal as possible.

[amaanq]

Not a blocker, but I'm not sure if the indentation for the closing paren was expected (if it is for visual distinction from the json punctuation, that's totally fine)

[jasonforal]

I was just keeping it consistent with existing usages of that macro, e.g.

datadog-static-analyzer/crates/cli/src/sarif/sarif_utils.rs

Lines 1171 to 1176 in f373619

	}
	}}],
	"version":"2.1.0"
	}
	);
	assert_json_eq!(expected_json, sarif_report_to_string);

I agree that it looks kinda weird, but we should handle any formatting changes in a separate PR if desired.