Automated fixes using check-google-doc-style (#193)

With one manual ignore in the markdown style proposal, because it's explicitly listing disallowed terms.

docs/project/evolution.md

@@ -253,10 +253,10 @@ community's engagement in it. Beyond the above structure, try to use
 or [BLUF](<https://en.wikipedia.org/wiki/BLUF_(communication)>) writing style to
 help readers rapidly skim the material.
 
-The proposal's pull request may include changes in the same repo. Please be
-thoughtful about how much effort you invest this way: it can help illustrate the
-intent of a proposal and avoid duplicating text in the proposal, but proposals
-may also need to be rewritten substantially or be deferred/declined.
+The proposal's pull request may include changes in the same repository. Please
+be thoughtful about how much effort you invest this way: it can help illustrate
+the intent of a proposal and avoid duplicating text in the proposal, but
+proposals may also need to be rewritten substantially or be deferred/declined.
 
 Where parts of a proposal may have several ways to address them, feel free to
 list options and mark them as "open questions". When describing an open
@@ -338,8 +338,9 @@ believe more changes are needed.
 When significant alternatives are pointed out, include them in the proposal
 regardless of whether they're adopted. The "alternatives" section should be used
 to document rejected alternatives as well as the original approach when an
-alternative is adopted, with pros and cons either way. New "open questions" may
-also be added where the author isn't confident about the best approach.
+alternative is adopted, with advantages and disadvantages either way. New "open
+questions" may also be added where the author isn't confident about the best
+approach.
 
 ##### Actions