UnitTestFrameworkPkg: Fix markdownlint issues

Fixes markdownlint issues introduced from edk2 cherry-picks.

Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>

.markdownlintignore

@@ -3,3 +3,4 @@
 
 # Ignore external dependencies
 *_extdep/
+UnitTestFrameworkPkg/Library/SubhookLib/

UnitTestFrameworkPkg/ReadMe.md

@@ -151,7 +151,7 @@ section so that the unit tests will be built.
 
 See this example in `UnitTestFrameworkPkg.dsc`...
 
-```
+```inf
 [Components]
   UnitTestFrameworkPkg/Test/UnitTest/Sample/SampleUnitTest/SampleUnitTestUefiShell.inf
 ```
@@ -160,7 +160,7 @@ Also, based on the type of tests that are being created, the associated DSC incl
 UnitTestFrameworkPkg for Host or Target based tests should also be included at the top of the DSC
 file.
 
-```
+```inf
 !include UnitTestFrameworkPkg/UnitTestFrameworkPkgTarget.dsc.inc
 ```
 
@@ -170,7 +170,7 @@ they should be added in the \<LibraryClasses\> sub-section for the INF file in t
 
 See this example in `SecurityPkgHostTest.dsc`...
 
-```
+```inf
 [Components]
   SecurityPkg/Library/SecureBootVariableLib/UnitTest/SecureBootVariableLibUnitTest.inf {
     <LibraryClasses>
@@ -325,8 +325,7 @@ To write more advanced tests, first look at all the Assertion and Logging macros
 Beyond that, if you're writing host-based tests and want to take a dependency on the UnitTestFrameworkPkg, you can
 leverage the `cmocka.h` interface and write tests with all the features of the Cmocka framework.
 
-Documentation for Cmocka can be found here:
-https://api.cmocka.org/
+Documentation for Cmocka can be found [here](https://api.cmocka.org/).
 
 ## GoogleTest Samples
 
@@ -389,7 +388,7 @@ section so that the unit tests will be built.
 
 See this example in `UnitTestFrameworkPkgHostTest.dsc`...
 
-```
+```inf
 #include <gtest/gtest.h>
 extern "C" {
   #include <Uefi.h>
@@ -445,6 +444,7 @@ int main(int argc, char* argv[]) {
   return RUN_ALL_TESTS();
 }
 ```
+
 However, while GoogleTest does not require test suites or test cases to be
 registered, there is still one rule within EDK II that currently needs to be
 followed. This rule is that all tests for a given GoogleTest application must
@@ -499,6 +499,7 @@ while the `EXPECT` version continues running the `TEST`.
 
 There is no return status from a GooglTest unit test. If no assertions (or expectations) are
 triggered then the unit test has a passing status.
+
 ### GoogleTest - A gMock Test Case
 
 Below is a sample test case from `SecureBootVariableLibGoogleTest`. Although
@@ -858,16 +859,18 @@ Host based Unit Tests will automatically enable coverage data.
 For Windows, this is primarily leverage for pipeline builds, but this can be leveraged locally using the
 OpenCppCoverage windows tool to parse coverage data to cobertura xml format.
 
-- Windows Prerequisite
-  ```bash
+* Windows Prerequisite
+
+  ```text
   Download and install https://github.com/OpenCppCoverage/OpenCppCoverage/releases
   python -m pip install --upgrade -r ./pip-requirements.txt
   stuart_ci_build -c .pytool/CISettings.py  -t NOOPT TOOL_CHAIN_TAG=VS2019 -p MdeModulePkg
   Open Build/coverage.xml
   ```
 
-  - How to see code coverage data on IDE Visual Studio
-    ```
+  * How to see code coverage data on IDE Visual Studio
+
+    ```text
     Open Visual Studio VS2019 or above version
     Click "Tools" -> "OpenCppCoverage Settings"
     Fill your execute file into "Program to run:"