Minor corrections to BotR intro chapter (#53746)

Just fixing up a couple of missing words I noticed in the intro chapter:
Missing "to" in "(more code that does not seem do much)"
Missing "a" in "This results in big productivity boost."

docs/design/coreclr/botr/intro-to-clr.md

@@ -110,7 +110,7 @@ In addition, there is another important ramification of managed code that may no
 
 The result of this is that unmanaged interfaces are almost always _wrapped_ before being exposed to managed code developers.  For example, when accessing files, you don't use the Win32 CreateFile functions provided by the operating system, but rather the managed System.IO.File class that wraps this functionality.  It is in fact extremely rare that unmanaged functionality is exposed to users directly.
 
-While this wrapping may seem to be "bad" in some way (more code that does not seem do much), it is in fact good because it actually adds quite a bit of value.  Remember it was always _possible_ to expose the unmanaged interfaces directly; we _chose_ to wrap the functionality.  Why?  Because the overarching goal of the runtime is to **make programming easy**, and typically the unmanaged functions are not easy enough.  Most often, unmanaged interfaces are _not_ designed with ease of use in mind, but rather are tuned for completeness.  Anyone looking at the arguments to CreateFile or CreateProcess would be hard pressed to characterize them as "easy." Luckily, the functionality gets a "facelift" when it enters the managed world, and while this makeover is often very "low tech" (requiring nothing more complex than renaming, simplification, and organizing the functionality), it is also profoundly useful.  One of the very important documents created for the CLR is the [Framework Design Guidelines][fx-design-guidelines].  This 800+ page document details best practices in making new managed class libraries.
+While this wrapping may seem to be "bad" in some way (more code that does not seem to do much), it is in fact good because it actually adds quite a bit of value.  Remember it was always _possible_ to expose the unmanaged interfaces directly; we _chose_ to wrap the functionality.  Why?  Because the overarching goal of the runtime is to **make programming easy**, and typically the unmanaged functions are not easy enough.  Most often, unmanaged interfaces are _not_ designed with ease of use in mind, but rather are tuned for completeness.  Anyone looking at the arguments to CreateFile or CreateProcess would be hard pressed to characterize them as "easy." Luckily, the functionality gets a "facelift" when it enters the managed world, and while this makeover is often very "low tech" (requiring nothing more complex than renaming, simplification, and organizing the functionality), it is also profoundly useful.  One of the very important documents created for the CLR is the [Framework Design Guidelines][fx-design-guidelines].  This 800+ page document details best practices in making new managed class libraries.
 
 Thus, we have now seen that managed code (which is intimately involved with the CLR) differs from unmanaged code in two important ways:
 
@@ -204,7 +204,7 @@ As an aside, while exceptions avoid one common error (not checking for failure),
 
 Previous to version 2.0 of the CLR, the only parameterized types were arrays.  All other containers (such as hash tables, lists, queues, etc.), all operated on a generic Object type.  The inability to create List<ElemT>, or Dictionary<KeyT, ValueT> certainly had a negative performance effect because value types needed to be boxed on entry to a collection, and explicit casting was needed on element fetch.  Nevertheless, that is not the overriding reason for adding parameterized types to the CLR.  The main reason is that **parameterized types make programming easier**.
 
-The reason for this is subtle.  The easiest way to see the effect is to imagine what a class library would look like if all types were replaced with a generic Object type.  This effect is not unlike what happens in dynamically typed languages like JavaScript.  In such a world, there are simply far more ways for a programmer to make incorrect (but type-safe) programs.  Is the parameter for that method supposed to be a list? a string? an integer? any of the above? It is no longer obvious from looking at the method's signature.  Worse, when a method returns an Object, what other methods can accept it as a parameter? Typical frameworks have hundreds of methods; if they all take parameters of type Object, it becomes very difficult to determine which Object instances are valid for the operations the method will perform.  In short, strong typing helps a programmer express their intent more clearly, and allows tools (e.g., the compiler) to enforce their intent.  This results in big productivity boost.
+The reason for this is subtle.  The easiest way to see the effect is to imagine what a class library would look like if all types were replaced with a generic Object type.  This effect is not unlike what happens in dynamically typed languages like JavaScript.  In such a world, there are simply far more ways for a programmer to make incorrect (but type-safe) programs.  Is the parameter for that method supposed to be a list? a string? an integer? any of the above? It is no longer obvious from looking at the method's signature.  Worse, when a method returns an Object, what other methods can accept it as a parameter? Typical frameworks have hundreds of methods; if they all take parameters of type Object, it becomes very difficult to determine which Object instances are valid for the operations the method will perform.  In short, strong typing helps a programmer express their intent more clearly, and allows tools (e.g., the compiler) to enforce their intent.  This results in a big productivity boost.
 
 These benefits do not disappear just because the type gets put into a List or a Dictionary, so clearly parameterized types have value.  The only real question is whether parameterized types are best thought of as a language specific feature which is "compiled out" by the time CIL is generated, or whether this feature should have first class support in the runtime.  Either implementation is certainly possible.  The CLR team chose first class support because without it, parameterized types would be implemented different ways by different languages.  This would imply that interoperability would be cumbersome at best.  In addition, expressing programmer intent for parameterized types is most valuable _at the interface_ of a class library.  If the CLR did not officially support parameterized types, then class libraries could not use them, and an important usability feature would be lost.