Issue #34: Add additional fixes for typos.

* Add additional fixes for typos.

Author: Gordon Brown

affinity/cpp-20/d0796r2.md

@@ -511,7 +511,7 @@ The `affinity_query` class template provides an abstraction for a relative affin
     friend expected<size_t, error_type> operator>=(const affinity_query&, const affinity_query&);
 
 *Returns:* An `expected<size_t, error_type>` where,
-* if the affinity query was succesful, the value of type `size_t` represents the magnitude of the relative affinity;
+* if the affinity query was successful, the value of type `size_t` represents the magnitude of the relative affinity;
 * if the affinity query was not successful, the error is an error of type `error_type` which represents the reason for affinity query failed.
 
 > [*Note:* An affinity query is permitted to fail if affinity between the two execution resources cannot be calculated for any reason, such as the resources are of different vendors or communication between the resources is not possible. *--end note*]
@@ -560,7 +560,7 @@ With the ability to place memory with affinity comes the ability to define algor
 
 ## Level of abstraction
 
-The current proposal provides an interface for querying whether an `execution_resource` can allocate and/or execute work, it can provide the concurrency it supports and it can provide a name. We also provide the `affinity_query` structure for querying the relative affinity metrics between two `execution_resource`s. However this may not be enough information for users to take full advance of the system, they may also want to know what kind of memory is available or the properties by which work is executed. It was decided that attempting to enumerate the various hardware components would not be ideal as that would make it harder for implementers to support new hardware. It has been discussed that a better approach would be to parameterise the additional properties of hardware such that hardware queries could be much more generic.
+The current proposal provides an interface for querying whether an `execution_resource` can allocate and/or execute work, it can provide the concurrency it supports and it can provide a name. We also provide the `affinity_query` structure for querying the relative affinity metrics between two `execution_resource`s. However this may not be enough information for users to take full advance of the system, they may also want to know what kind of memory is available or the properties by which work is executed. It was decided that attempting to enumerate the various hardware components would not be ideal as that would make it harder for implementors to support new hardware. It has been discussed that a better approach would be to parameterize the additional properties of hardware such that hardware queries could be much more generic.
 
 We may wish to mirror the design of the executors proposal and have a generic query interface using properties for querying information about an `execution_resource`. It’s expected that an implementation may provide additional nonstandard queries that are specific to that implementation.
 
@@ -570,7 +570,7 @@ We may wish to mirror the design of the executors proposal and have a generic qu
 
 ## Dynamic topology discovery
 
-The current proposal requires that all `execution_resource`s are initialised before `main` is called, therefore not allowing an `execution_resource` to become available or go offline at runtime. We may wish to support this in the future, however this is outside of the scope of this paper.
+The current proposal requires that all `execution_resource`s are initialized before `main` is called, therefore not allowing an `execution_resource` to become available or go offline at runtime. We may wish to support this in the future, however this is outside of the scope of this paper.
 
 | Straw Poll |
 |------------|