[mlir][docs] Fix broken links to traits documentation (#82131)

It seems the `Traits.md` file was turned into `Traits/_index.md` in
https://reviews.llvm.org/D153291, causing links to `Traits.md` to no
longer work (instead, `Traits` needs to be used).

Author: mlevesquedion

mlir/docs/DefiningDialects/AttributesAndTypes.md

@@ -305,7 +305,7 @@ MLIR includes several specialized classes for common situations:
 Similarly to operations, Attribute and Type classes may attach `Traits` that
 provide additional mixin methods and other data. `Trait`s may be attached via
 the trailing template argument, i.e. the `traits` list parameter in the example
-above. See the main [`Trait`](../Traits.md) documentation for more information
+above. See the main [`Trait`](../Traits) documentation for more information
 on defining and using traits.
 
 ### Interfaces

mlir/docs/Interfaces.md

@@ -132,7 +132,7 @@ methods that are overridden by the `Model` that is templated on the concrete
 entity type. It is important to note that these classes should be pure, and
 should not contain non-static data members or other mutable data. To attach an
 interface to an object, the base interface classes provide a
-[`Trait`](Traits.md) class that can be appended to the trait list of that
+[`Trait`](Traits) class that can be appended to the trait list of that
 object.
 
 ```c++
@@ -420,7 +420,7 @@ comprised of the following components:
     -   A C++ code block containing additional verification applied to the
         operation that the interface is attached to.
     -   The structure of this code block corresponds 1-1 with the structure of a
-        [`Trait::verifyTrait`](Traits.md) method.
+        [`Trait::verifyTrait`](Traits) method.
 
 ##### Interface Methods
 
@@ -457,7 +457,7 @@ Interface methods are comprised of the following components:
     -   This implementation is placed within the `Trait` class that is attached
         to the IR entity, and does not directly affect any of the interface
         classes. As such, this method has the same characteristics as any other
-        [`Trait`](Traits.md) method.
+        [`Trait`](Traits) method.
     -   `ConcreteAttr`/`ConcreteOp`/`ConcreteType` is an implicitly defined
         `typename` that can be used to refer to the type of the derived IR
         entity currently being operated on.
@@ -601,7 +601,7 @@ def MyInterface : OpInterface<"MyInterface"> {
       };
       ```
 
-      As detailed in [Traits](Traits.md), given that each operation implementing
+      As detailed in [Traits](Traits), given that each operation implementing
       this interface will also add the interface trait, the methods on this
       interface are inherited by the derived operation. This allows for
       injecting a default implementation of this method into each operation that

mlir/docs/LangRef.md

@@ -49,7 +49,7 @@ using familiar concepts of compiler [Passes](Passes.md). Enabling an arbitrary
 set of passes on an arbitrary set of operations results in a significant scaling
 challenge, since each transformation must potentially take into account the
 semantics of any operation. MLIR addresses this complexity by allowing operation
-semantics to be described abstractly using [Traits](Traits.md) and
+semantics to be described abstractly using [Traits](Traits) and
 [Interfaces](Interfaces.md), enabling transformations to operate on operations
 more generically. Traits often describe verification constraints on valid IR,
 enabling complex invariants to be captured and checked. (see
@@ -234,7 +234,7 @@ their regions. For instance, the scope of values in a region with
 [SSA control flow semantics](#control-flow-and-ssacfg-regions) is constrained
 according to the standard definition of
 [SSA dominance](https://en.wikipedia.org/wiki/Dominator_\(graph_theory\)).
-Another example is the [IsolatedFromAbove trait](Traits.md/#isolatedfromabove),
+Another example is the [IsolatedFromAbove trait](Traits/#isolatedfromabove),
 which restricts directly accessing values defined in containing regions.
 
 Function identifiers and mapping identifiers are associated with
@@ -478,7 +478,7 @@ the enclosing region, if any. By default, operations inside a region can
 reference values defined outside of the region whenever it would have been legal
 for operands of the enclosing operation to reference those values, but this can
 be restricted using traits, such as
-[OpTrait::IsolatedFromAbove](Traits.md/#isolatedfromabove), or a custom
+[OpTrait::IsolatedFromAbove](Traits/#isolatedfromabove), or a custom
 verifier.
 
 Example:

mlir/docs/PassManagement.md

@@ -362,7 +362,7 @@ specific operation, and executed on any viable operation type). Operation types
 anchor pass managers must adhere to the following requirement:
 
 *   Must be registered and marked
-    [`IsolatedFromAbove`](Traits.md/#isolatedfromabove).
+    [`IsolatedFromAbove`](Traits/#isolatedfromabove).
 
     *   Passes are expected not to modify operations at or above the current
         operation being processed. If the operation is not isolated, it may

mlir/docs/SymbolsAndSymbolTables.md

@@ -8,7 +8,7 @@ around this nesting structure; including the processing of operations within the
 [pass manager](PassManagement.md/#pass-manager). One advantage of the MLIR
 design is that it is able to process operations in parallel, utilizing multiple
 threads. This is possible due to a property of the IR known as
-[`IsolatedFromAbove`](Traits.md/#isolatedfromabove).
+[`IsolatedFromAbove`](Traits/#isolatedfromabove).
 
 Without this property, any operation could affect or mutate the use-list of
 operations defined above. Making this thread-safe requires expensive locking in

mlir/docs/Tutorials/Toy/Ch-2.md

@@ -245,7 +245,7 @@ This operation takes zero operands, a
 `value` to represent the constant value, and returns a single result of
 [RankedTensorType](../../Dialects/Builtin.md/#rankedtensortype). An operation class 
 inherits from the [CRTP](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern)
-`mlir::Op` class which also takes some optional [*traits*](../../Traits.md) to
+`mlir::Op` class which also takes some optional [*traits*](../../Traits) to
 customize its behavior. `Traits` are a mechanism with which we can inject
 additional behavior into an Operation, such as additional accessors,
 verification, and more. Let's look below at a possible definition for the