Use static diagnostic names and cache Rules

[ntBre]

This PR is stacked on #18074 and uses the
separation between CacheMessage and the other diagnostic types added there to
store a Rule directly on CacheMessage and convert it back to a &'static str for use by Diagnostic and DiagnosticMessage.

In the first commit, I added a generated Rule::pascal_name method for converting
back to the Pascal-case name currently used by Diagnostic and DiagnosticMessage,
but in the second commit I used the heck crate to generalize our existing kebab_case
macro to convert the ViolationMetadata::rule_name output to kebab-case and use
kebab-case everywhere. heck was already in our dependency graph because it's what
strum uses internally for case conversions.

I think that's probably preferable long-term, but it might be a breaking change in
the LSP because the lint name is used as the title for a quick fix, if a suggestion is
unavailable. Otherwise Diagnostic::name is only used for debug! logging.

Test Plan

Existing tests

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

ℹ️ ecosystem check encountered format errors. (no format changes; 1 project error)

openai/openai-cookbook (error)

warning: Detected debug build without --no-cache.
error: Failed to read examples/gpt4-1_prompting_guide.ipynb: Expected a Jupyter Notebook, which must be internally stored as JSON, but this file isn't valid JSON: expected `,` or `]` at line 580 column 29

Formatter (preview)

ℹ️ ecosystem check encountered format errors. (no format changes; 1 project error)

openai/openai-cookbook (error)

ruff format --preview

warning: Detected debug build without --no-cache.
error: Failed to read examples/gpt4-1_prompting_guide.ipynb: Expected a Jupyter Notebook, which must be internally stored as JSON, but this file isn't valid JSON: expected `,` or `]` at line 580 column 29

[MichaReiser]

Nice speed up.

This is great. I would probably remove the heck dependency again, given that we already had an implementation of kebab_case (also reduces the size of your PR).

My only concern is that name is also used in the GitLab reporter to compute a fingerprint

ruff/crates/ruff_linter/src/message/gitlab.rs

Lines 126 to 134 in 981bd70

	fn fingerprint(message: &Message, project_path: &str, salt: u64) -> u64 {
	let mut hasher = DefaultHasher::new();
	salt.hash(&mut hasher);
	message.name().hash(&mut hasher);
	project_path.hash(&mut hasher);
	hasher.finish()
	}

This means, all diagnostics will be changed for gitlab users.

I don't think I'm too concerned by this because the implementation already uses std::hash::DefaultHasher which isn't guaranteed to be stable across rustc versions (or even platforms! we should probably fix this).

[ntBre]

Oh interesting about the gitlab diagnostic. As soon as I saw it was being hashed, I assumed it was okay. From the gitlab docs, it sounds like they shouldn't be too user-facing and only used to deduplicate entries in the merge request widget, so hopefully it's okay.

[ntBre]

Hm, it does look like we marked a previous change to the hash as breaking: #7159. One other benefit of keeping heck is that we could potentially go the other way back to pascal-case and (temporarily) use that for the gitlab emitter, if we want to avoid a breaking change.