Minor carbon-explorer edit to roadmap (#1225)

A rephrasing was suggested on https://github.com/carbon-language/carbon-lang/pull/1188#discussion_r851416370 because "explorer" alone could be hard to parse; I'm suggesting just replacing with "Carbon explorer" to get precision without changing phrasing, as well as rephrasing "Executable semantic" as "Carbon explorer" (which... the former *may* have meant "executable semantics", but the difference in pluralization made it vague, so I'm not sure this is right -- but it also didn't explain _where_, so "executable semantics" seems the right reading)

Co-authored-by: Geoff Romer <gromer@google.com>

docs/project/roadmap.md

@@ -18,7 +18,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
     -   [Example ports of C++ libraries to Carbon (100% of woff2, 99% of RE2)](#example-ports-of-c-libraries-to-carbon-100-of-woff2-99-of-re2)
         -   [Language design covers the syntax and semantics of the example port code.](#language-design-covers-the-syntax-and-semantics-of-the-example-port-code)
     -   [Demo implementation of core features with working examples](#demo-implementation-of-core-features-with-working-examples)
-    -   [Executable semantic specification for core features with test cases](#executable-semantic-specification-for-core-features-with-test-cases)
+    -   [Carbon explorer implementation of core features with test cases](#carbon-explorer-implementation-of-core-features-with-test-cases)
 -   [Beyond 2022](#beyond-2022)
     -   [Potential 2023 goals: finish 0.2 language, stop experimenting](#potential-2023-goals-finish-02-language-stop-experimenting)
     -   [Potential 2024-2025 goals: _ship_ 1.0 language & organization](#potential-2024-2025-goals-_ship_-10-language--organization)
@@ -45,8 +45,8 @@ and it should be possible to write non-trivial Carbon programs.
 An initial rough framework for the core standard library functionality should be
 provided, as necessary to support the core language components. A largely
 complete implementation of the core language design should be available in
-explorer. The toolchain should be able to parse the core language design, with
-some support for name lookup and type-checking.
+Carbon explorer. The toolchain should be able to parse the core language design,
+with some support for name lookup and type-checking.
 
 We should have begun writing non-trivial portions of the standard library, such
 as common higher-level data structures and algorithms.
@@ -120,7 +120,7 @@ overarching value proposition.
 
 We should have a clear understanding of the syntax and semantics used by these
 example ports. We should be able to demonstrate that self-contained portions of
-the ported code work correctly using the explorer implementation.
+the ported code work correctly using Carbon explorer.
 
 ### Demo implementation of core features with working examples
 
@@ -163,13 +163,13 @@ but the long term focus should be on end-to-end user metrics.
 Automatic code formatting could be achieved many ways, but it seems useful to
 ensure the language and implementation both support use cases like formatting.
 
-### Executable semantic specification for core features with test cases
+### Carbon explorer implementation of core features with test cases
 
 This should include both a human readable rendering of the formal semantics as
 well as an execution environment to run test cases through those semantics. The
 implementation should cover enough of the core language that example code, such
 as the above ports of woff2 and RE2 and the Carbon standard library, can be
-verified with the explorer implementation.
+verified with Carbon explorer.
 
 ## Beyond 2022