feat: add additional FeatureKind entries for debug features

[dyc3]

Summary

In the playground, we currently hard code which languages can do what with naive conditions based on the filename. This aims to make it so we don't need to constantly update the playground as file capabilities change.

This also fixes the de/serialization of the FeatureName type.

Test Plan

CI should pass. Unsure how to test this with my local version of the playground.

[codspeed-hq]

CodSpeed Performance Report

Merging #3892 will improve performances by 22.95%

_{Comparing 09-14-feat_add_additional_featurekind_entries_for_debug_features (cc70b3d) with main (6922305)}

Summary

⚡ 1 improvements
✅ 106 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	09-14-feat_add_additional_featurekind_entries_for_debug_features	Change
⚡	eucjp_1600564308684076393.json[uncached]	1,190.2 µs	968 µs	+22.95%

[ematipico]

Syntax and formatter IR aren't needed. If a file can be handled, it can be parsed, hence it can emit a CST. If a file can be formatted, it can emit a IR.

Control flow is a black sheep. I suppose we can add it

[dyc3]

The debug methods can technically be unimplemented, and that leads to throwing errors in the playground.

For example, the html file handler is currently in this state:

biome/crates/biome_service/src/file_handlers/html.rs

Lines 59 to 83 in 1792846

	impl ExtensionHandler for HtmlFileHandler {
	fn capabilities(&self) -> Capabilities {
	Capabilities {
	parser: ParserCapabilities { parse: Some(parse) },
	debug: DebugCapabilities {
	debug_syntax_tree: None,
	debug_control_flow: None,
	debug_formatter_ir: None,
	},
	analyzer: AnalyzerCapabilities {
	lint: None,
	code_actions: None,
	rename: None,
	fix_all: None,
	organize_imports: None,
	},
	formatter: FormatterCapabilities {
	format: Some(format),
	format_range: None,
	format_on_type: None,
	},
	search: SearchCapabilities { search: None },
	}
	}
	}

I think having these will generally reduce the friction when adding new languages.

[ematipico]

The debug methods can technically be unimplemented

That is true for all methods, and it should be the the client to deal with that. That's a design decision because various clients, even servers, can consume the Workspace. When used by servers, all methods can technically fail, that's why even methods that don't need to return Result, they do.

Unfortunately, JS doesn't provide any signature for when a method can throw an error at runtime, so we are stuck with what we have.

Regarding the FeatureKind. I think we should reduce the proposed changes to a single FeatureKind::Debug, because that's in line with what we have today. For example, we have ::Format, not ::Formating/::FormatOnType/::FormatRange. It will be up to us to implement all the debugging features at once.