Contributing: clarify what the exceptions are intended to cover

In a recent discussion around a networking submission, it was
pointed out that "exceptions" could be more specific [1]. In other
words, the "to simplify the upstreaming process" wording in
the webpage may not be sufficient.

Thus clarify it further with similar notes/examples as those given
in the Zulip discussion.

In addition, link to the recently added "Out-of-tree modules" page
for further details on those.

Link: https://rust-for-linux.zulipchat.com/#narrow/stream/396592-Networking/topic/NAPI.20Abstractions/near/386129495 [1]
Signed-off-by: Miguel Ojeda <[email protected]>

src/Contributing.md

@@ -66,7 +66,9 @@ For new abstractions and modules, and especially for those that require new kern
 
     This way, you can get early design feedback before the actual patch submission later, and the discussion is focused on the given subsystem (rather than the prerequisites).
 
-  - In general, the kernel does not allow to integrate code without users, but exceptions can potentially be made for Rust code to simplify the upstreaming process early on. Please contact the Rust maintainers for help, especially if you find yourself with a lot of dependencies or patches for unrelated subsystems.
+  - In general, the kernel does not allow to integrate code without users, but exceptions can potentially be made for Rust code to simplify the upstreaming process early on. That is, upstreaming some dependencies first so that it is easier to upstream expected in-tree users later on. However, note that this is not meant to be a way to justify upstreaming APIs that do not have agreed upon in-tree users. In particular, [out-of-tree modules](Out-of-tree-modules.md) do not constitute a user in this context.
+
+    Please contact the Rust maintainers for help, especially if you find yourself with a lot of dependencies or patches for unrelated subsystems.
 
 ## Submitting patches