Fixing document to reflect the current state (#213)

# Preface

Please ensure you have read the [contribution
docs](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md) prior
to submitting the pull request. In particular,
[pull request
guidelines](https://github.com/microsoft/mu/blob/master/CONTRIBUTING.md#pull-request-best-practices).

## Description

There has been a few movements since the last documentation update:
1. The policy producers are centralized to a common module.
2. Added a new tool to read the applied configuration through the host
OS.

For each item, place an "x" in between `[` and `]` if true. Example:
`[x]`.
_(you can also check items in the GitHub UI)_

- [ ] Impacts functionality?
- **Functionality** - Does the change ultimately impact how firmware
functions?
- Examples: Add a new library, publish a new PPI, update an algorithm,
...
- [ ] Impacts security?
- **Security** - Does the change have a direct security impact on an
application,
    flow, or firmware?
  - Examples: Crypto algorithm change, buffer overflow fix, parameter
    validation improvement, ...
- [ ] Breaking change?
- **Breaking change** - Will anyone consuming this change experience a
break
    in build or boot behavior?
- Examples: Add a new library class, move a module to a different repo,
call
    a function in a new library class in a pre-existing module, ...
- [ ] Includes tests?
  - **Tests** - Does the change include any explicit test code?
  - Examples: Unit tests, integration tests, robot tests, ...
- [x] Includes documentation?
- **Documentation** - Does the change contain explicit documentation
additions
    outside direct code modifications (and comments)?
- Examples: Update readme file, add feature readme file, link to
documentation
    on an a separate Web page, ...

## How This Was Tested

This is just documentation updates.

## Integration Instructions

N/A

SetupDataPkg/Docs/Overview/Overview.md

@@ -117,6 +117,9 @@ file, binary, or SVD.
 [Profiles doc](../Profiles/Overview.md).
 - The variable list binary, saved in .vl format, can be applied to a running system via dmpstore in the EFI shell,
 or via [WriteConfVarListToUefiVars.py](../../Tools/WriteConfVarListToUefiVars.py).
+- Vice versa, variables applied to target system can be fetch through ConfApp's dump configuration option in UEFI, saved
+to a file system in the EFI shell via dmpstore, or by [ReadUefiVarsToConfVarList.py](../../Tools/ReadUefiVarsToConfVarList.py)
+in the OS.
 - The SVD can be applied to a running system via USB/serial via mu_feature_config's Conf App.
 - Changes to the XML itself will result in a change to the default configuration options of a platform.
 

SetupDataPkg/Docs/PlatformIntegration/PlatformIntegrationSteps.md

@@ -66,9 +66,8 @@ configure the hardware accordingly.
 
 ## Platform Data Flow
 
-The default silicon policy should be initialized by silicon modules during early PEI after Policy Service is available.
-An example is provided in
-[mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/PolicyDataGfx/PolicyDataGfx.c).
+The default silicon policy can be initialized by silicon modules during early PEI after Policy Service is available, and
+then updated by a phase-2 module to apply the changes from configuration data to silicon policy.
 
 The OemConfigPolicyCreator should take the autogenerated data provided by PlatformConfigDataLib (via the `gKnobData`
 extern structure) and publish the config policy. This module can perform any filtering required by the OEM/platform,
@@ -82,6 +81,13 @@ Following these two operations, the n number of Config Policy to Silicon Policy
 policy and override the relevant silicon policies. An example is provided in
 [mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/ConfigKnobs/ConfigKnobs.c).
 
+Note that, for demonstration simplicity and data overhead reduction, the provided example above directly intialized the
+silicon policy and update the value using data from configuration autogen headers. In real world, this same model could
+also be considered as long as this model would not cause dependency intervention. More often though, existing silicon modules
+from major silicon vendors might already have their data pipelines, such as setup variables, structured PCDs. In those cases,
+platforms can consider updating the data that resides in the existing pipelines instead of introducing major silicon module
+overhaul.
+
 During the rest of boot process, the silicon drivers will consume the updated silicon policies to configure hardware
 components or adjust firmware configuration. An example is provided in
 [mu_tiano_platforms](https://github.com/microsoft/mu_tiano_platforms/blob/HEAD/Platforms/QemuQ35Pkg/QemuVideoDxe/Driver.c).