[Documentation] Add guidelines for grouping tests together

[davide]

Summary

After our discussion on IRC. Please forgive my bad english =)

[mehdi_amini]

TestingGuide.rst

243 ↗

(On Diff #40348)

It is a good practice is worthless without a motivation, I think Eric needs to feed something here :)

[echristo]

LGTM.

Motivation: Fewer processes spawned for tests, this is particularly good on OSes that have slow forking code like OSX and Windows. Easier to find "what are the tests that are associated with this feature". I'm sure if you think about it you can probably come up with a few more. :)

[mehdi_amini]

If launching less processes is a motivation, then not adding FileCheck when not needing (crash test) should be good practice :)

[echristo]

In D14733#290586, @joker.eph wrote:

If launching less processes is a motivation, then not adding FileCheck when not needing (crash test) should be good practice :)

Nope. Because you should have a check for some sort of reasonable behavior if possible. :)

llvm/trunk/docs/TestingGuide.rst

 everything enclosed as one value.
 
 In general, you should strive to keep your RUN lines as simple as possible,
 using them only to run tools that generate textual output you can then examine.
 The recommended way to examine output to figure out if the test passes is using
 the :doc:`FileCheck tool <CommandGuide/FileCheck>`. *[The usage of grep in RUN
 lines is deprecated - please do not send or commit patches that use it.]*
 
+Put related tests into a single file rather than having a separate file per
+test. Check if there are files already covering your feature and consider
+adding your code there instead of creating a new file.
+
 Extra files
 -----------
 
 If your test requires extra files besides the file containing the ``RUN:``
 lines, the idiomatic place to put them is in a subdirectory ``Inputs``.
 You can then refer to the extra files as ``%S/Inputs/foo.bar``.
 
 For example, consider ``test/Linker/ident.ll``. The directory structure is