[Docs] Clarify that FunctionPasses can't add/remove declarations

[aeubanks]

Summary

In preparation for potential future concurrency, a FunctionPass
shouldn't modify anything at the module level that other FunctionPasses
can also modify.

[arsenm]

How is this supposed to work practically? A huge number of functions passes want to add intrinsic declarations

[aeubanks]

Ideally they'd be module passes, like in https://reviews.llvm.org/D86178.
It does look like some existing legacy and NPM function passes break this rule. Maybe I should revert and ask more explicitly on llvm-dev. WDYT?

[arsenm]

In D89890#2347728, @aeubanks wrote:

Ideally they'd be module passes, like in https://reviews.llvm.org/D86178.
It does look like some existing legacy and NPM function passes break this rule. Maybe I should revert and ask more explicitly on llvm-dev. WDYT?

I would bet the majority of passes do (e.g. InstCombine, and pretty much any target IR pass). In the past the guidance was adding declarations is OK (I thought last time this came up, this was noted somewhere in the documentation)

llvm/docs/WritingAnLLVMPass.rst

 ``FunctionPass`` execute on each function in the program independent of all of
 the other functions in the program.  ``FunctionPass``\ es do not require that
 they are executed in a particular order, and ``FunctionPass``\ es do not modify
 external functions.
 
 To be explicit, ``FunctionPass`` subclasses are not allowed to:
 
 #. Inspect or modify a ``Function`` other than the one currently being processed.
-#. Add or remove ``Function``\ s from the current ``Module``.
+#. Add or remove ``Function``\ s from the current ``Module``, including
+   declarations.
 #. Add or remove global variables from the current ``Module``.
 #. Maintain state across invocations of :ref:`runOnFunction
    <writing-an-llvm-pass-runOnFunction>` (including global data).
 
 Implementing a ``FunctionPass`` is usually straightforward (See the :ref:`Hello
 World <writing-an-llvm-pass-basiccode>` pass for example).
 ``FunctionPass``\ es may overload three virtual methods to do their work.  All
 of these methods should return ``true`` if they modified the program, or