Improve generated dump debugging instructions (#46493)

* Improve generated dump debugging instructions

* Update eng/testing/debug-dump-template.md

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

* Update eng/testing/debug-dump-template.md

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

* Update eng/testing/debug-dump-template.md

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

* Update debug-dump-template.md

* Fix ```

* fix some ```cmd

* Reverse .cmd to .bat

* Open only for reading

* Improve foldername

* Install only one SOS

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

docs/workflow/README.md

@@ -24,7 +24,7 @@ For Linux and macOS
 ```
 
 For Windows:
-```bat
+```cmd
 build.cmd
 ```
 

docs/workflow/building/libraries/README.md

@@ -4,7 +4,7 @@
 
 Here is one example of a daily workflow for a developer working mainly on the libraries, in this case using Windows:
 
-```bat
+```cmd
 :: From root:
 git clean -xdf
 git pull upstream master & git push origin master
@@ -60,7 +60,7 @@ For Linux:
 ```
 
 For Windows:
-```bat
+```cmd
 ./build.cmd -rc Release
 ```
 

docs/workflow/building/mono/README.md

@@ -16,7 +16,7 @@ To build a complete runtime environment, you need to build both the Mono runtime
 ./build.sh --subset mono+libs
 ```
 or on Windows,
-```bat
+```cmd
 build.cmd -subset mono+libs
 ```
 Note that the debug configuration is the default option. It generates a 'debug' output and that includes asserts, fewer code optimizations, and is easier for debugging. If you want to make performance measurements, or just want tests to execute more quickly, you can also build the 'release' version which does not have these checks by adding the flag `-configuration release` (or `-c release`).
@@ -28,7 +28,7 @@ Once you've built the complete runtime and assuming you want to work with just m
 ./build.sh --subset mono
 ```
 or on Windows,
-```bat
+```cmd
 build.cmd -subset mono
 ```
 When the build completes, product binaries will be dropped in the `artifacts\bin\mono\<OS>.<arch>.<flavor>` folder.
@@ -69,7 +69,7 @@ To generate nuget packages:
 ./build.sh --subset mono -pack (with optional release configuration)
 ```
 or on Windows,
-```bat
+```cmd
 build.cmd -subset mono -pack (with optional release configuration)
 ```
 

docs/workflow/testing/using-corerun.md

@@ -30,7 +30,7 @@ Consider that you already have a .NET application DLL called HelloWorld.dll and
 (You could make such a DLL by using 'dotnet new' 'dotnet restore' 'dotnet build' in a 'HelloWorld' directory).
 
 If you execute the following
-```bat
+```cmd
     set PATH=%PATH%;%CoreCLR%\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root\
     set CORE_LIBRARIES=%ProgramFiles%\dotnet\shared\Microsoft.NETCore.App\1.0.0
 
@@ -64,7 +64,7 @@ your new runtime.
 When you execute 'runtime/src/tests/build.cmd' one of the things that it does is set up a directory where it
 gathers the CoreCLR that has just been built with the pieces of the class library that tests need.
 It places this runtime in the directory
-```bat
+```cmd
     runtime\artifacts\tests\coreclr\<OS>.<Arch>.<BuildType>\Tests\Core_Root
 ```
 off the CoreCLR Repository.    The way the tests are expected to work is that you set the environment
@@ -72,12 +72,12 @@ variable CORE_ROOT to this directory
 (you don't have to set CORE_LIBRARIES) and you can run any tests.  For example after building the tests
 (running src\tests\build from the repository base) and running 'src\tests\run') you can do the following
 
-```bat
+```cmd
     set PATH=%PATH%;%CoreCLR%\artifacts\Product\windows.x64.Debug
     set CORE_ROOT=%CoreCLR%\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root
 ```
 sets you up so that corerun can run any of the test.   For example
-```bat
+```cmd
     corerun artifacts\tests\coreclr\windows.X64.Debug\GC\Features\Finalizer\finalizeio\finalizeio\finalizeio.exe
 ```
 runs the finalizerio test.

docs/workflow/testing/using-your-build.md

@@ -33,7 +33,7 @@ For another small walkthrough see [Dogfooding .NET SDK](https://github.com/dotne
 
 At this point, you can create a new 'Hello World' program in the standard way.
 
-```bat
+```cmd
 mkdir HelloWorld
 cd HelloWorld
 dotnet new console
@@ -57,7 +57,7 @@ For Windows you will want `win-x64`, for macOS `osx-x64` and `linux-x64` for Lin
 Now is the time to publish. The publish step will trigger restore and build. You can iterate on build by calling `dotnet build` as
 needed.
 
-```bat
+```cmd
 dotnet publish
 ```
 
@@ -106,11 +106,11 @@ deploy your new bits. In a lot of cases it is easiest to just copy everything fr
 
 You can build just the .NET Library part of the build by doing (debug, for release add 'release' qualifier)
 (on Linux / OSX us ./build.sh)
-```bat
+```cmd
     .\build skiptests skipnative
 ```
 Which builds System.Private.CoreLib.dll if you modify C# code. If you wish to only compile the coreclr.dll you can do
- ```bat
+ ```cmd
     .\build skiptests skipmscorlib
 ```
 Note that this technique does not work on .NET Apps that have not been published (that is you have not created

docs/workflow/using-dotnet-cli.md

@@ -104,7 +104,7 @@ static void Main(string[] args)
 Now is the time to publish. The publish step will trigger restore and build. You can iterate on build by calling `dotnet build` as
 needed.
 
-```bat
+```cmd
 dotnet publish
 ```
 
@@ -179,7 +179,7 @@ So the steps are:
 
 ### 1. Build the package again
 
-```bat
+```cmd
 build.cmd clr+libs+host+packs -c release
 ``` 
 
@@ -187,13 +187,13 @@ If you only changed libraries, `build.cmd libs+host+packs -c release` is a littl
 
 ### 2. Delete your local package cache
 
-```bat
+```cmd
 rd /s /q c:\localcache
 ```
 
 ### 3. Publish again
 
-```bat
+```cmd
 dotnet publish
 ```