docs(design): improve readability (#1431)

Readability improvements focused on `docs/design/.md`

Signed-off-by: Ryan Russell <git@ryanrussell.org>

docs/design/README.md

@@ -1240,7 +1240,7 @@ fn Foo() -> f32 {
 _Nominal classes_, or just
 [_classes_](<https://en.wikipedia.org/wiki/Class_(computer_programming)>), are a
 way for users to define their own
-[data strutures](https://en.wikipedia.org/wiki/Data_structure) or
+[data structures](https://en.wikipedia.org/wiki/Data_structure) or
 [record types](<https://en.wikipedia.org/wiki/Record_(computer_science)>).
 
 This is an example of a class
@@ -2962,7 +2962,7 @@ operators or the comma operator. In the unlikely situation where those operators
 need to be overridden for a Carbon type, that can be done with a nonmember C++
 function.
 
-Carbon intefaces with no C++ equivalent, such as
+Carbon interfaces with no C++ equivalent, such as
 [`CommonTypeWith(U)`](#common-type), may be implemented for C++ types externally
 in Carbon code. To satisfy the orphan rule
 ([1](generics/details.md#impl-lookup), [2](generics/details.md#orphan-rule)),

docs/design/classes.md

@@ -409,7 +409,7 @@ base class. In the cases where such access is needed, the workaround is to
 access them through C++ functions.
 
 We do not expect idiomatic Carbon-only code to use multiple inheritance.
-Extending this design to support interopating with C++ types using multiple
+Extending this design to support interoperating with C++ types using multiple
 inheritance is future work.
 
 ### Mixins

docs/design/code_and_name_organization/README.md

@@ -24,7 +24,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Libraries](#libraries)
         -   [Exporting entities from an API file](#exporting-entities-from-an-api-file)
         -   [Granularity of libraries](#granularity-of-libraries)
-        -   [Exporting namespces](#exporting-namespces)
+        -   [Exporting namespaces](#exporting-namespaces)
     -   [Imports](#imports-1)
         -   [Imports from the current package](#imports-from-the-current-package)
     -   [Namespaces](#namespaces)
@@ -392,7 +392,7 @@ possibly containing only a single class. The choice of only allowing a single
 `api` file per library should help encourage developers to write small
 libraries.
 
-#### Exporting namespces
+#### Exporting namespaces
 
 Any entity may be marked with `api` except for namespace and package entities.
 That is, `api namespace Sha256;` is invalid code. Instead, namespaces are

docs/design/control_flow/return.md

@@ -163,7 +163,7 @@ avoid copies.
 
 > **TODO:** Have some discussion of RVO and NRVO as they are found in C++ here,
 > and the fact that Carbon provides the essential part of these as first-class
-> featuers and therefore they are never "optimizations" or done implicitly or
+> features and therefore they are never "optimizations" or done implicitly or
 > optionally.
 
 ## Alternatives considered

docs/design/expressions/bitwise.md

@@ -174,7 +174,7 @@ integer constant and a value of integer type, as follows:
     converted to the integer type and the computation is performed as described
     [above](#integer-types).
 -   If the second operand of a bit-shift operator is an integer constant and the
-    first opreand is not, and the second operand is between 0 (inclusive) and
+    first operand is not, and the second operand is between 0 (inclusive) and
     the bit-width of the first operand (exclusive), the integer constant is
     converted to an integer type that can hold its value and the computation is
     performed as described above.

docs/design/expressions/implicit_conversions.md

@@ -104,7 +104,7 @@ The following implicit numeric conversions are available:
 -   `iN` or `uN` -> `iM` if `M` > `N`
 -   `uN` -> `uM` if `M` > `N`
 -   `fN` -> `fM` if `M` > `N`
--   `iN` or `uN` -> `fM` if every value of type `iN` or `uN` can be represeted
+-   `iN` or `uN` -> `fM` if every value of type `iN` or `uN` can be represented
     in `fM`:
     -   `i12` or `u11` (or smaller) -> `f16`
     -   `i25` or `u24` (or smaller) -> `f32`

docs/design/generics/details.md

@@ -1266,7 +1266,7 @@ To write an interface extending multiple interfaces, use multiple `extends`
 declarations. For example, the
 [`BinaryInteger` protocol in Swift](https://developer.apple.com/documentation/swift/binaryinteger)
 inherits from `CustomStringConvertible`, `Hashable`, `Numeric`, and `Stridable`.
-The [`SetAlgeba` protocol](https://swiftdoc.org/v5.1/protocol/setalgebra/)
+The [`SetAlgebra` protocol](https://swiftdoc.org/v5.1/protocol/setalgebra/)
 extends `Equatable` and `ExpressibleByArrayLiteral`, which would be declared in
 Carbon:
 
@@ -4255,7 +4255,7 @@ Luckily, Rust team members have done a lot of blogging during their design
 process, so Carbon can benefit from the work they have done. However, getting
 specialization to work for Rust is complicated by the need to maintain
 compatibility with existing Rust code. This motivates a number of Rust rules
-where Carbon can be simpler. As a result there are both similarites and
+where Carbon can be simpler. As a result there are both similarities and
 differences between the Carbon and Rust plans:
 
 -   A Rust impl defaults to not being able to be specialized, with a `default`
@@ -4420,7 +4420,7 @@ expressions match:
 
 -   If the type part is omitted, it is rewritten to `Self` in the context of the
     declaration.
--   `Self` is rewritted to its meaning in the scope it is used. In a class
+-   `Self` is rewritten to its meaning in the scope it is used. In a class
     scope, this should match the type name and optional parameter expression
     after `class`. So in `class MyClass extends MyBase { ... }`, `Self` is
     rewritten to `MyClass`. In `class Vector(T:! Movable) { ... }`, `Self` is

docs/design/interoperability/README.md

@@ -10,12 +10,12 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 ## Table of contents
 
--   [Philsophy and goals](#philsophy-and-goals)
+-   [Philosophy and goals](#philosophy-and-goals)
 -   [Overview](#overview)
 
 <!-- tocstop -->
 
-## Philsophy and goals
+## Philosophy and goals
 
 The C++ interoperability layer of Carbon allows a subset of C++ APIs to be
 accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed