fix(tools): preserve raw-string contents when detecting Rust function boundaries(#889)

[tecnolgd]

Summary

Fixed tools/format-rust.py lexical stripping logic to correctly track raw string literals (r"...", r#"..."#, br#"..."#, etc.) instead of treating internal quotes and braces as standard code blocks.
This prevents embedded fake function syntax inside raw strings from tricking top-level function boundary detection.

Motivation

Closes #889

Previously, lexical content stripping lacked proper raw-string literal state tracking, leading to misidentified function boundaries when strings contained braces or keywords.

Target and compatibility impact

None

Validation

• Tested multi-line raw strings (r#"..."#), extended hashes (r###"..."###), and byte-raw strings (br#"..."#) samples.
• Verified that formatting is fully idempotent across multiple consecutive script runs.

Checklist

• Commits include a DCO Signed-off-by line.
• Tests cover new behavior or the PR explains why no test is needed.
• User-facing changes include documentation or diagnostics updates.
• The change preserves the license boundary between the compiler and std/.

[LunaStev]

Thanks for the fix! The raw-string handling is a useful improvement.

I found one regression that needs to be addressed before merging.

In strip_lexical_content(), the new isinstance(state["string"], int) check also matches True, because Python's bool is a subclass of int.

Since ordinary strings use state["string"] = True, they are incorrectly handled as raw strings with one hash, causing the lexer to look for "# instead of ".

Please distinguish ordinary-string state from raw-string hash counts explicitly (for example, using type(...) is int or a dedicated state representation).

Please also add regression tests covering ordinary strings, raw strings with different hash counts, byte raw strings, multiline strings, and repeated formatting for idempotency.

It would also be useful to verify that raw-string prefixes are recognised only at valid token boundaries.

Once these are addressed, this should be ready for another review. Thanks!

[tecnolgd]

Thanks for the feedback, @LunaStev.

I've addressed the PR as per the review and python3 tools/test_format_rust.py passes all test cases. Please let me know if anything needs to be changed.