Add test discovery documentation for test addons

[vinistock]

Motivation

Step towards #3421

This PR adds documentation for the test discovery process that add-ons can contribute. I decided to not put command resolution and custom reporters in the same PR because it would make it too long to review.

I also made this a dedicated file under add-ons. It's complex enough that it warrants longer examples with more detailed explanations.

[vinistock]

• Add test discovery documentation for test addons #3488 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[alexcrocha]

Looks good 💪
Added a couple suggestions and a few nits.

[alexcrocha]

We should list what the 3 parts are, and update with links when they're available.

Suggested change

	There are 3 main parts for contributing support for a new framework, which will be discussed in separate sections.
	There are 3 main parts for contributing support for a new framework:
	- [Test discovery](#test-discovery): Identifying tests within the codebase and their structure.
	- Command resolution: Determining how to execute a specific test or group of tests.
	- Custom reporting: Displaying test execution results in the Test Explorer.```

[alexcrocha]

Suggested change

	Test discovery is the process of populating the explorer view with which tests exist in the codebase. The Ruby LSP
	Test discovery is the process of populating the explorer view with the tests that exist in the codebase. The Ruby LSP

nit

[alexcrocha]

Suggested change

	Now, we have to implement the listener. If the test framework being handled uses classes to define test groups, like
	Next, the listener itself needs to be implemented. If the test framework being handled uses classes to define test groups, like

[alexcrocha]

Suggested change

	# modules inside a test file and they are not all runnable tests
	# modules inside a test file and not all of them are runnable tests

nit

[alexcrocha]

Suggested change

	# Create the test item for the example. To make IDs unique, always include the group names as part of it since
	# users can define the same exact example name in multiple different groups
	# Create the test item for the example. To make IDs unique, always include the group names as part of the ID,
	# since users can define the same exact example name in multiple different groups

nit

[alexcrocha]

Suggested change

	There's an implicit requirement for test item IDs. Groups must be separated by `::` and examples must be separated
	Test item IDs have an implicit formatting requirement: Groups must be separated by `::` and examples must be separated

[alexcrocha]

Suggested change

	For frameworks that do not define test groups using classes, such as RSpec, the listener should not inherit from
	`RubyLsp::Listeners::TestDiscovery` and the whole logic can be implemented directly based on the specific rules for
	that tool.
	For frameworks that do not define test groups using classes, such as RSpec, the listener should not inherit from
	`RubyLsp::Listeners::TestDiscovery`. Instead, the logic can be implemented directly, based on the framework's specific
	rules.

[domingo2000]

1. Is this implicit ID requirement necesary just for the listeners inheriting from RubyLsp::Listeners::TestDiscovery or is for all the addons?.
2. Is for example MyTest::some group#test something valid?, Or it has to be underscored without spaces. A regex could be usefull to know the exact required syntax. Because spec like styles do not conform so well to the Module::Class#method syntax.