Clarify note about supported target types in "Defining test functions" article

[stmontgomery]

This adjusts the wording of a - Note: in our Defining test functions documentation article which advises that users only import the testing library in test targets. It expands the kinds of supported targets to include "library targets meant for test targets", which is a supported use case.

Motivation:

The wording should not imply that it's never supported to vend a library which extends the testing library. There is an important distinction between libraries which are distributed to end users (e.g. those bundles within apps or alongside executables) vs. libraries intended solely to support test targets or other testing libraries.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

[stmontgomery]

Open to suggestions for better phrasing @iamleeg, but I hope my intent is clear!

[iamleeg]

Looks good, thank you!

[jerryjrchen]

Very nit: would it be clearer to say "library used only in test targets"? I can see the original wording as being interpreted overly broadly (e.g. some sort of utils used in both an executable and test library)

[stmontgomery]

I see what you're going for there. I worded it this way to keep it slightly more open because it's also supported (though less common) to have one test-only library which is used exclusively by another test-only library which in turn is used by exclusively by test targets. So the guidance is really "keep the transitive closure of these libraries confined to testing contexts". It's just that I'd like this doc phrasing to read naturally. So I felt "meant for test targets" captured that well enough, without excluding that use case

[grynspan]

This for example is valid in a library if you are building from source:

#if canImport(Testing)
public func foo(_ test: Test) {
  ...
}
#endif