Typo fixes in proposals (#1965)

Some errors and typos in the proposals

proposals/p0029.md

@@ -132,7 +132,7 @@ Disadvantages:
 -   Bisection and continuous integration are more complex.
     -   May create difficulty for continuous integration against mainline,
         because unclear what "order" they should be applied / explored. While
-        there are technical approaches to address this, the don't seem to
+        there are technical approaches to address this, they don't seem to
         eliminate the complexity, merely provide a clear set of mechanics for
         handling it.
 -   Reduces incentives to land small, incremental changes by allowing

proposals/p0107.md

@@ -869,7 +869,7 @@ Disadvantages:
             simultaneously. As a result, if a user types `Boost.` and requests a
             tab completion, the system must have all libraries from all packages
             loaded for an accurate result.
-        -   Although many features can restricted to _current_ imports, some
+        -   Although many features can be restricted to _current_ imports, some
             features, such as
             [auto-imports](https://www.jetbrains.com/help/idea/creating-and-optimizing-imports.html),
             examine _possible_ imports. Large codebases may have a

proposals/p0676.md

@@ -132,9 +132,9 @@ The main benefits of this approach were:
     the approach recommended by this proposal.
 
 The main objections to this approach was that it was context-sensitive and there
-was a lack of syntactic consistency in the context. That is, the were two kinds
-of context, generic and dynamic, and two kinds of brackets, square and parens,
-but sometimes the parens would be generic and sometimes not.
+was a lack of syntactic consistency in the context. That is, there were two
+kinds of context, generic and dynamic, and two kinds of brackets, square and
+parens, but sometimes the parens would be generic and sometimes not.
 
 #### Square brackets
 

proposals/p0818.md

@@ -36,9 +36,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 ## Problem
 
-We want to Carbon to have a high quality generics feature that achieves the
-goals set out in [#24](https://github.com/carbon-language/carbon-lang/pull/24).
-This is too big to land in a single proposal. This proposal continues
+We want Carbon to have a high quality generics feature that achieves the goals
+set out in [#24](https://github.com/carbon-language/carbon-lang/pull/24). This
+is too big to land in a single proposal. This proposal continues
 [#553](https://github.com/carbon-language/carbon-lang/pull/553) defining the
 details of:
 
@@ -438,10 +438,10 @@ variables and `==` for concrete type case.
 
 Other languages, such as Swift and Rust, don't require `observe` declarations or
 casting for the compiler to recognize two types as transitively equal. The
-problem is that there is know way to know how many equality constraints need to
-be considered before being able to conclude whether two type expressions are
-equal. In fact, the equality relations form a semi-group, where in general
-deciding whether two sequences are equivalent is undecidable, see
+problem is that there is no way to know how many equality constraints need to be
+considered before being able to conclude whether two type expressions are equal.
+In fact, the equality relations form a semi-group, where in general deciding
+whether two sequences are equivalent is undecidable, see
 [Swift type checking is undecidable - Discussion - Swift Forums](https://forums.swift.org/t/swift-type-checking-is-undecidable/39024).
 
 #### Restricted equality constraints

proposals/p0875.md

@@ -490,7 +490,7 @@ _Efficient and simple compilation:_ This approach leads to a simpler compilation
 strategy. However, in the absence of forward declarations, every compilation
 referring to an entity needs to have a build dependency on the full definition
 of that entity, meaning there is no physical separation between the APIs of
-entities and their definitions. This would imposes a potentially-significant
+entities and their definitions. This would impose a potentially-significant
 build time cost due to increased recompilations when the definition of an entity
 changes.