[MLIR][docs] Clarify language in pass restrictions

[GMNGeoffrey]

Summary

Right now all but the last bullet are relying on applied "must not" that
isn't there and the last bullet is a "must".

mlir/docs/PassManagement.md

 In MLIR, the main unit of abstraction and transformation is an
 [operation](LangRef.md/#operations). As such, the pass manager is designed to
 work on instances of operations at different levels of nesting. The structure of
 the [pass manager](#pass-manager), and the concept of nesting, is detailed
 further below. All passes in MLIR derive from `OperationPass` and adhere to the
 following restrictions; any noncompliance will lead to problematic behavior in
 multithreaded and other advanced scenarios:
 
-*   Modify any state referenced or relied upon outside the current being
-    operated on. This includes adding or removing operations from the parent
-    block, changing the attributes(depending on the contract of the current
-    operation)/operands/results/successors of the current operation.
-*   Modify the state of another operation not nested within the current
+*   Must not modify any state referenced or relied upon outside the current
+    being operated on. This includes adding or removing operations from the
+    parent block, changing the attributes(depending on the contract of the
+    current operation)/operands/results/successors of the current operation.
+*   Must not modify the state of another operation not nested within the current
     operation being operated on.
     *   Other threads may be operating on these operations simultaneously.
-*   Inspect the state of sibling operations.
+*   Must not inspect the state of sibling operations.
     *   Other threads may be modifying these operations in parallel.
     *   Inspecting the state of ancestor/parent operations is permitted.
-*   Maintain mutable pass state across invocations of `runOnOperation`. A pass
-    may be run on many different operations with no guarantee of execution
-    order.
+*   Must not maintain mutable pass state across invocations of `runOnOperation`.
+    A pass may be run on many different operations with no guarantee of
+    execution order.
     *   When multithreading, a specific pass instance may not even execute on
         all operations within the IR. As such, a pass should not rely on running
         on all operations.
-*   Maintain any global mutable state, e.g. static variables within the source
-    file. All mutable state should be maintained by an instance of the pass.
+*   Must not maintain any global mutable state, e.g. static variables within the
+    source file. All mutable state should be maintained by an instance of the
+    pass.
 *   Must be copy-constructible
     *   Multiple instances of the pass may be created by the pass manager to
         process operations in parallel.
 
 When creating an operation pass, there are two different types to choose from
 depending on the usage scenario:
 
 ### OperationPass : Op-Specific