README.md: More idiomatic Markdown usage (#9799)

- In essence, use backticks where applicable.
- Also, changed some incorrect case (`Build.cmd` vs `build.cmd` which is the canonical name; if you have your git repo on a case-sensitive filesystem like I do, this makes a real difference - you can't run it with the incorrect case).
- Fixed naming of Git and CMake to use their official capitalization.

diff --git a/README.md b/README.md
index 98dcb1a..9d9bc8b 100644 (file)
--- a/README.md
+++ b/README.md
@@ -63,30 +63,30 @@ It also contains the source code for the following closely related support packa
 
 ## Relationship with the [CoreFX](https://github.com/dotnet/corefx) Repository 
 
-By itself, the Microsoft.NETCore.Runtime.CoreCLR package is actually not enough to do much.
+By itself, the `Microsoft.NETCore.Runtime.CoreCLR` package is actually not enough to do much.
 One reason for this is that the CoreCLR package tries to minimize the amount of the class library that it implements.
 Only types that have a strong dependency on the internal workings of the runtime are included (e.g, 
-System.Object, System.String System.Thread, System.Threading.Tasks.Task and most foundational interfaces).
+`System.Object`, `System.String`, `System.Thread`, `System.Threading.Tasks.Task` and most foundational interfaces).
 Instead most of the class library is implemented as independent Nuget packages that simply use the .NET Core 
-runtime as a dependency.    Many of the most familiar classes (System.Collections, System.IO, System.Xml and 
+runtime as a dependency.    Many of the most familiar classes (`System.Collections`, `System.IO`, `System.Xml` and 
 so on), live in packages defined in the [dotnet/corefx](https://github.com/dotnet/corefx) repository.
 
 But the main reason you can't do much with CoreCLR is that **ALL** of the types in the class library **LOOK** 
 like they are defined by the CoreFX framework and not CoreCLR.   Any library code defined here 
-lives in a single DLL called System.Private.CoreLib.dll and as its name suggests is private (hidden).
+lives in a single DLL called `System.Private.CoreLib.dll` and as its name suggests is private (hidden).
 Instead for any particular PUBLIC type defined in CoreCLR, we found the 'right' package in CoreFX where it naturally 
 belongs and use that package as its **public publishing** point.   That 'facade' package then forwards references 
-to the (private) implementation in System.Private.CoreLib.dll defined here.
-For example the *System.Runtime* package defined in CoreFX declares the PUBLIC name for types like 
-System.Object and System.String.   Thus from an applications point of view these types live in System.Runtime.dll. 
-However, System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately to System.Private.CoreLib.dll 
+to the (private) implementation in `System.Private.CoreLib.dll` defined here.
+For example the *`System.Runtime`* package defined in CoreFX declares the PUBLIC name for types like 
+`System.Object` and `System.String`.   Thus from an applications point of view these types live in `System.Runtime.dll`. 
+However, `System.Runtime.dll` (defined in the CoreFX repo) forwards references ultimately to `System.Private.CoreLib.dll` 
 which is defined here.
 
-Thus in order to run an application, you need BOTH the Microsoft.NETCore.Runtime.CoreCLR Nuget package 
+Thus in order to run an application, you need BOTH the `Microsoft.NETCore.Runtime.CoreCLR` Nuget package 
 (defined in this repository) as well as  packages for whatever you actually reference that were defined 
-in the CoreFX repository (which at a minimum includes the System.Runtime package).    You also need some 
+in the CoreFX repository (which at a minimum includes the `System.Runtime` package).    You also need some 
 sort of 'host' executable that loads the CoreCLR package as well as the CoreFX packages and starts your code (typically 
-you use dotnet.exe for this).   
+you use `dotnet.exe` for this).   
 
 These extra pieces are not defined here, however you don't need to build them in order to use the CoreCLR 
 Nuget package you create here.   There are already versions of the CoreFX packages published on 
@@ -106,8 +106,8 @@ the procedure are equally applicable to this repository.
 --------------------------
 ## Building the Repository
 
-The build depends on GIT, CMAKE, Python and of course a C++ compiler.  Once these prerequisites are installed
-the build is simply a matter of invoking the 'Build' script (Build.cmd or build.sh) at the base of the 
+The build depends on Git, CMake, Python and of course a C++ compiler.  Once these prerequisites are installed
+the build is simply a matter of invoking the 'build' script (`build.cmd` or `build.sh`) at the base of the 
 repository.  
 
 The details of installing the components differ depending on the operating system.  See the following
@@ -132,7 +132,7 @@ build all the tests.   There are quite a few tests so this does take a significa
 that is not necessary if you want to experiment with changes.   You can submit the building
 of the tests with the 'skiptests' argument to the build script.
 
-Thus to get a build as quickly as possible type the following (using \ as the directory separator, use / on Unix machines)
+Thus to get a build as quickly as possible type the following (using `\` as the directory separator, use `/` on Unix machines)
 ```bat
     .\build skiptests 
 ```
@@ -144,8 +144,8 @@ to build the release (full speed) flavor.  You can find more build options with
 
 ## Using Your Build
 
-The build places all of its generated files under the 'bin' directory at the base of the repository.   There 
-is a 'bin\Log' directory that contains log files generated during the build (Most useful when the build fails).
+The build places all of its generated files under the `bin` directory at the base of the repository.   There 
+is a `bin\Log` directory that contains log files generated during the build (Most useful when the build fails).
 The the actual output is placed in a directory like this 
 
 * bin\Product\Windows_NT.x64.Release