Set up Prettier for formatting, and run files through it. (#7)

CONTRIBUTING.md replaces the mention of Google style guide (which isn't automated) with Prettier (which should do most of the hauling). The rest is the formatter.

README.md

@@ -57,9 +57,9 @@ migration of large existing codebases. They are specifically designed to not
 require complete rewrites, new programming models, or building an entire new
 stack/ecosystem. However, there is no comparable option for C++ today:
 
-*   JavaScript → TypeScript
-*   Java → Kotlin
-*   C++ → **???**
+- JavaScript → TypeScript
+- Java → Kotlin
+- C++ → **???**
 
 Carbon explores what it would look like to fill this gap and align it with the
 above priorities.
@@ -75,12 +75,12 @@ It is important to understand that **this is a science experiment**, not a
 production effort. There are several initial questions that we want to explore
 and answer with this experiment:
 
-*   Can we deliver a design and implementation that is familiar and compelling
-    to C++ programmers and supports our goals?
-*   How seamless and effective can we make interoperability?
-*   How easy and scalable can we make migration?
-*   Will a significant segment of the ecosystem and industry adopt Carbon given
-    these tradeoffs?
+- Can we deliver a design and implementation that is familiar and compelling to
+  C++ programmers and supports our goals?
+- How seamless and effective can we make interoperability?
+- How easy and scalable can we make migration?
+- Will a significant segment of the ecosystem and industry adopt Carbon given
+  these tradeoffs?
 
 We are committed to learning the answers to these questions, but that may well
 not result in a production language. There is a very real chance that this
@@ -100,38 +100,37 @@ We hope that eventually Carbon will provide **significant advantages compared to
 today's C++**. Areas where we think we can most dramatically improve C++ for
 both software systems and developers are:
 
-*   A cohesive and principled language design, even when supporting advanced
-    features.
-*   Making common coding patterns safe by default whenever practical, with
-    affordable security mitigations available for any unsafety.
-    *   We will provide static checks for as many safety issues as we can by
-        default.
-    *   We will provide a spectrum of build modes with different trade-offs
-        between dynamic safety and performance. For example:
-        *   The default build mode will include as many dynamic safety checks as
-            we can while keeping the software's performance reasonable for
-            normal development, testing, and debugging.
-        *   Release builds will favor performance, with opt-in dynamic safety
-            checks and security mitigations for applications with higher
-            security requirements.
-    *   Over time, we also expect to both track and drive research into
-        increasing the degree of safety available without compromising our other
-        goals.
-*   Keeping our core language implementation simple, fast, and easily extended
-    in ways that will make all of our language tools better.
-*   Providing an effective, open, and inclusive language evolution process
-    aligned with our goals and priorities.
+- A cohesive and principled language design, even when supporting advanced
+  features.
+- Making common coding patterns safe by default whenever practical, with
+  affordable security mitigations available for any unsafety.
+  - We will provide static checks for as many safety issues as we can by
+    default.
+  - We will provide a spectrum of build modes with different trade-offs between
+    dynamic safety and performance. For example:
+    - The default build mode will include as many dynamic safety checks as we
+      can while keeping the software's performance reasonable for normal
+      development, testing, and debugging.
+    - Release builds will favor performance, with opt-in dynamic safety checks
+      and security mitigations for applications with higher security
+      requirements.
+  - Over time, we also expect to both track and drive research into increasing
+    the degree of safety available without compromising our other goals.
+- Keeping our core language implementation simple, fast, and easily extended in
+  ways that will make all of our language tools better.
+- Providing an effective, open, and inclusive language evolution process aligned
+  with our goals and priorities.
 
 Carbon will also aim to allow a single layer of a legacy C++ library stack to be
 migrated to Carbon, without migrating the code above or below. This will make it
 easier for developers to start using Carbon. Key features underpin Carbon's
 compatibility and interoperability with C++:
 
-*   The memory, execution, and threading model will be compatible with C++.
-*   Access to existing C++ types, interfaces, and even templates will be
-    provided as part of the core language.
-*   Carbon will be able to export types, interfaces, and templates for
-    consumption by C++.
+- The memory, execution, and threading model will be compatible with C++.
+- Access to existing C++ types, interfaces, and even templates will be provided
+  as part of the core language.
+- Carbon will be able to export types, interfaces, and templates for consumption
+  by C++.
 
 **However, Carbon's approach still requires a nearly complete re-engineering of
 the language as well as large-scale migration for users.** This is extremely
@@ -142,6 +141,6 @@ very high.
 
 Carbon's main repositories are:
 
-*   **carbon-lang** - Carbon language specification and documentation.
-*   **carbon-toolchain** - Carbon language toolchain and reference implementation.
-*   **carbon-proposals** - An archive of reviewed Carbon language proposals.
+- **carbon-lang** - Carbon language specification and documentation.
+- **carbon-toolchain** - Carbon language toolchain and reference implementation.
+- **carbon-proposals** - An archive of reviewed Carbon language proposals.