Incorporate fixes from editorial

Edits from <rdar://150071036>.

Co-authored-by: Colleen Toporek <colleen_toporek@apple.com>

Author: amartini51

TSPL.docc/LanguageGuide/Generics.md

@@ -19,7 +19,7 @@ or indeed an array for any other type that can be created in Swift.
 Similarly, you can create a dictionary to store values of any specified type,
 and there are no limitations on what that type can be.
 
-## The Problem That Generics Solve
+## The Problem that Generics Solve
 
 Here's a standard, nongeneric function called `swapTwoInts(_:_:)`,
 which swaps two `Int` values:
@@ -1958,17 +1958,17 @@ is a sequence of integers.
 ## Implicit Constraints
 
 In addition to the constraints you write explicitly,
-many places in your code
-also implicitly include an constraint
-that types conform to some very common protocols
+many places in your generic code
+also include implicit constraints
+that require types to conform to some very common protocols
 like [`Copyable`][].
 <!-- When SE-0446 is implemented, add Escapable above -->
 For information on when a protocol is implied,
 see the reference for that protocol.
 
 [`Copyable`]: https://developer.apple.com/documentation/swift/copyable
 
-This constraint is implicit because
+These constraints are implicit because
 almost all types in Swift conform to these protocols,
 so you specify only the exceptions.
 For example, both of the following function declarations
@@ -1984,7 +1984,7 @@ require the generic type parameter `MyType` to be copyable.
 In the first version, the constraint is implicit;
 the second version lists the explicitly.
 In most code,
-types also implicitly conform to these common protocol.
+types also implicitly conform to these common protocols.
 For more information,
 see <doc:Protocols#Implicit-Conformance-to-a-Protocol>.
 

TSPL.docc/LanguageGuide/OpaqueTypes.md

@@ -23,7 +23,7 @@ Boxed protocol types don't preserve type identity ---
 the value's specific type isn't known until runtime,
 and it can change over time as different values are stored.
 
-## The Problem That Opaque Types Solve
+## The Problem that Opaque Types Solve
 
 For example,
 suppose you're writing a module that draws ASCII art shapes.

TSPL.docc/LanguageGuide/Protocols.md

@@ -752,7 +752,7 @@ a nonfailable initializer or an implicitly unwrapped failable initializer.
   ```
 -->
 
-## Protocols That Have Only Semantic Requirements
+## Protocols that Have Only Semantic Requirements
 
 All of the example protocols above require some methods or properties,
 but a protocol declaration doesn't have to include any requirements.
@@ -799,10 +799,10 @@ struct MyStruct: Copyable {
 extension MyStruct: BitwiseCopyable { }
 ```
 
-The code above defines a new structure
+The code above defines a new structure.
 Because `Copyable` has only semantic requirements,
 there isn't any code in the structure declaration to adopt the protocol.
-Likewise, because `BitwiseCopyable` has only semantic requirements,
+Similarly, because `BitwiseCopyable` has only semantic requirements,
 the extension that adopts that protocol has an empty body.
 
 You usually don't need to write conformance to these protocols ---
@@ -1469,7 +1469,7 @@ XXX SE-0390 uses the same example but ~Copyable -- is that better?
 The code above shows part of a wrapper around POSIX file descriptors.
 The `FileDescriptor` structure
 satisfies all of the requirements of the `Sendable` protocol,
-which would normally make it sendable.
+which normally makes it sendable.
 However,
 writing `~Sendable` suppresses this implicit conformance.
 Even though file descriptors use integers