[mlir][docs] Fix links to index and integer types

[mehdi_amini]

Thanks!

mlir/docs/Dialects/Affine.md

 # 'affine' Dialect
 
 This dialect provides a powerful abstraction for affine operations and analyses.
 
 [TOC]
 
 ## Polyhedral Structures
 
 MLIR uses techniques from polyhedral compilation to make dependence analysis and
 loop transformations efficient and reliable. This section introduces some of the
 core concepts that are used throughout the document.
 
 ### Dimensions and Symbols
 
 Dimensions and symbols are the two kinds of identifiers that can appear in the
-polyhedral structures, and are always of [`index`](../LangRef.md#index-type)
+polyhedral structures, and are always of [`index`](Builtin.md#indextype)
 type. Dimensions are declared in parentheses and symbols are declared in square
 brackets.
 
 Examples:
 
 ```mlir
 // A 2d to 3d affine mapping.
 // d0/d1 are dimensions, s0 is a symbol

 `ceildiv` is the ceiling function which maps the result of the division of its
 first argument by its second argument to the smallest integer greater than or
 equal to that result. `floordiv` is a function which maps the result of the
 division of its first argument by its second argument to the largest integer
 less than or equal to that result. `mod` is the modulo operation: since its
 second argument is always positive, its results are always positive in our
 usage. The `integer-literal` operand for ceildiv, floordiv, and mod is always
 expected to be positive. `bare-id` is an identifier which must have type
-[index](../LangRef.md#index-type). The precedence of operations in an affine
+[index](Builtin.md#indextype). The precedence of operations in an affine
 expression are ordered from highest to lowest in the order: (1)
 parenthesization, (2) negation, (3) modulo, multiplication, floordiv, and
 ceildiv, and (4) addition and subtraction. All of these operators associate from
 left to right.
 
 A _multidimensional affine expression_ is a comma separated list of
 one-dimensional affine expressions, with the entire list enclosed in
 parentheses.

mlir/docs/Dialects/SPIR-V.md

 [SpirvTools]: https://github.com/KhronosGroup/SPIRV-Tools
 [Rationale]: ../Rationale/#block-arguments-vs-phi-nodes
 [ODS]: ../OpDefinitions.md
 [GreedyPatternRewriter]: https://github.com/llvm/llvm-project/blob/main/mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp
 [MlirDialectConversionTypeConversion]: ../DialectConversion.md#type-converter
 [MlirDialectConversionRewritePattern]: ../DialectConversion.md#conversion-patterns
 [MlirDialectConversionSignatureConversion]: ../DialectConversion.md#region-signature-conversion
 [MlirOpInterface]: ../Interfaces/#operation-interfaces
-[MlirIntegerType]: ../LangRef.md#integer-type
+[MlirIntegerType]: Builtin.md#integertype
 [MlirFloatType]: ../LangRef.md#floating-point-types
 [MlirVectorType]: ../LangRef.md#vector-type
 [MlirMemrefType]: ../LangRef.md#memref-type
-[MlirIndexType]: ../LangRef.md#index-type
+[MlirIndexType]: Builtin.md#indextype
 [MlirGpuDialect]: ../Dialects/GPU.md
 [MlirStandardDialect]: ../Dialects/Standard.md
 [MlirSpirvHeaders]: https://github.com/llvm/llvm-project/tree/main/mlir/include/mlir/Dialect/SPIRV
 [MlirSpirvLibs]: https://github.com/llvm/llvm-project/tree/main/mlir/lib/Dialect/SPIRV
 [MlirSpirvTests]: https://github.com/llvm/llvm-project/tree/main/mlir/test/Dialect/SPIRV
 [MlirSpirvUnittests]: https://github.com/llvm/llvm-project/tree/main/mlir/unittests/Dialect/SPIRV
 [MlirGpuToSpirvHeaders]: https://github.com/llvm/llvm-project/tree/main/mlir/include/mlir/Conversion/GPUToSPIRV
 [MlirGpuToSpirvLibs]: https://github.com/llvm/llvm-project/tree/main/mlir/lib/Conversion/GPUToSPIRV

mlir/docs/Tutorials/DefiningAttributesAndTypes.md

 
 As described above, `Type` objects in MLIR are value-typed and rely on having an
 implicit internal storage object that holds the actual data for the type. When
 defining a new `Type` it isn't always necessary to define a new storage class.
 So before defining the derived `Type`, it's important to know which of the two
 classes of `Type` we are defining:
 
 Some types are _singleton_ in nature, meaning they have no parameters and only
-ever have one instance, like the [`index` type](LangRef.md#index-type).
+ever have one instance, like the [`index` type](../Dialects/Builtin.md#indextype).
 
 Other types are _parametric_, and contain additional information that
 differentiates different instances of the same `Type`. For example the
-[`integer` type](LangRef.md#integer-type) contains a bitwidth, with `i8` and
+[`integer` type](../Dialects/Builtin.md#integertype) contains a bitwidth, with `i8` and
 `i16` representing different instances of
-[`integer` type](LangRef.md#integer-type). _Parametric_ may also contain a
+[`integer` type](../Dialects/Builtin.md#integertype). _Parametric_ may also contain a
 mutable component, which can be used, for example, to construct self-referring
 recursive types. The mutable component _cannot_ be used to differentiate
 instances of a type class, so usually such types contain other parametric
 components that serve to identify them.
 
 #### Singleton types
 
 For singleton types, we can jump straight into defining the derived type class.

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

 that holds the actual data for the type. The `Type` class in itself acts as a
 simple wrapper around an internal `TypeStorage` object that is uniqued within an
 instance of an `MLIRContext`. When constructing a `Type`, we are internally just
 constructing and uniquing an instance of a storage class.
 
 When defining a new `Type` that contains parametric data (e.g. the `struct`
 type, which requires additional information to hold the element types), we will
 need to provide a derived storage class. The `singleton` types that don't have
-any additional data (e.g. the [`index` type](../../LangRef.md#index-type)) don't
+any additional data (e.g. the [`index` type](../../Dialects/Builtin.md#indextype)) don't
 require a storage class and use the default `TypeStorage`.
 
 ##### Defining the Storage Class
 
 Type storage objects contain all of the data necessary to construct and unique a
 type instance. Derived storage classes must inherit from the base
 `mlir::TypeStorage` and provide a set of aliases and hooks that will be used by
 the `MLIRContext` for uniquing. Below is the definition of the storage instance