[mlir][doc] Fix typos in tutorial chapters

[Lewuathe]

Summary

Fix several typos in Toy tutorial chapters.

• Chapter 2
• Chapter 5

[Lewuathe]

@jpienaar Thank you for reviewing the change. I do not have the right to commit this change in the repository. Could you check-in the change on behalf of me?

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

 compiler passes - does not include locations in the output by default. The
 `-mlir-print-debuginfo` flag specifies to include locations. (Run `mlir-opt
 --help` for more options.)
 
 ### Opaque API
 
 MLIR is designed to allow most IR elements, such as attributes,
 operations, and types, to be customized. At the same time, IR
-elements can always be reduced to the above fundmental concepts. This
+elements can always be reduced to the above fundamental concepts. This
 allows MLIR to parse, represent, and
 [round-trip](../../../getting_started/Glossary.md#round-trip) IR for
 *any* operation. For example, we could place our Toy operation from
 above into an `.mlir` file and round-trip through *mlir-opt* without
 registering any dialect:
 
 ```mlir
 func @toy_func(%tensor: tensor<2x3xf64>) -> tensor<3x2xf64> {
   %t_tensor = "toy.transpose"(%tensor) { inplace = true } : (tensor<2x3xf64>) -> tensor<3x2xf64>
   return %t_tensor : tensor<3x2xf64>
 }
 ```
 
 In the cases of unregistered attributes, operations, and types, MLIR
 will enforce some structural constraints (SSA, block termination,
 etc.), but otherwise they are completely opaque. For instance, MLIR
-has little information about whether an unregisted operation can
+has little information about whether an unregistered operation can
 operate on particular datatypes, how many operands it can take, or how
 many results it produces. This flexibility can be useful for
 bootstrapping purposes, but it is generally advised against in mature
 systems. Unregistered operations must be treated conservatively by
 transformations and analyses, and they are much harder to construct
 and manipulate.
 
 This handling can be observed by crafting what should be an invalid IR for Toy

 Above we introduce several of the concepts for defining operations in the ODS
 framework, but there are many more that we haven't had a chance to: regions,
 variadic operands, etc. Check out the
 [full specification](../../OpDefinitions.md) for more details.
 
 ## Complete Toy Example
 
 We can now generate our "Toy IR". You can build `toyc-ch2` and try yourself on
-the above example: `toyc-ch2 test/Examples/Toy/Ch2/codegen.toy -emit=mlir 
--mlir-print-debuginfo`. We can also check our RoundTrip: `toyc-ch2 
-test/Examples/Toy/Ch2/codegen.toy -emit=mlir -mlir-print-debuginfo 2> 
-codegen.mlir` followed by `toyc-ch2 codegen.mlir -emit=mlir`. You should also 
+the above example: `toyc-ch2 test/Examples/Toy/Ch2/codegen.toy -emit=mlir
+-mlir-print-debuginfo`. We can also check our RoundTrip: `toyc-ch2
+test/Examples/Toy/Ch2/codegen.toy -emit=mlir -mlir-print-debuginfo 2>
+codegen.mlir` followed by `toyc-ch2 codegen.mlir -emit=mlir`. You should also
 use `mlir-tblgen` on the final definition file and study the generated C++ code.
 
 At this point, MLIR knows about our Toy dialect and operations. In the
 [next chapter](Ch-3.md), we will leverage our new dialect to implement some
 high-level language-specific analyses and transformations for the Toy language.

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

void ToyToAffineLoweringPass::runOnFunction() {
   target.addIllegalDialect<ToyDialect>();
   target.addLegalOp<PrintOp>();
   ...
 }
 ```
 
 Above, we first set the toy dialect to illegal, and then the print operation
 as legal. We could have done this the other way around.
-Individual operations always take precendence over the (more generic) dialect
+Individual operations always take precedence over the (more generic) dialect
 definitions, so the order doesn't matter. See `ConversionTarget::getOpInfo`
 for the details.
 
 ## Conversion Patterns
 
 After the conversion target has been defined, we can define how to convert the
 *illegal* operations into *legal* ones. Similarly to the canonicalization
 framework introduced in [chapter 3](Ch-3.md), the
func @main() {
   dealloc %1 : memref<2x3xf64>
   dealloc %0 : memref<3x2xf64>
   return
 }
 ```
 
 Here, we can see that a redundant allocation was removed, the two loop nests
 were fused, and some unnecessary `load`s were removed. You can build `toyc-ch5`
-and try yourself: `toyc-ch5 test/Examples/Toy/Ch5/affine-lowering.mlir 
+and try yourself: `toyc-ch5 test/Examples/Toy/Ch5/affine-lowering.mlir
 -emit=mlir-affine`. We can also check our optimizations by adding `-opt`.
 
 In this chapter we explored some aspects of partial lowering, with the intent to
 optimize. In the [next chapter](Ch-6.md) we will continue the discussion about
 dialect conversion by targeting LLVM for code generation.