Add RT DXE Shared Crypto [Rebase & FF]

[makubacki]

Description

Closes #55

Primary purpose is to add Runtime DXE shared crypto. Other fixes and
updates are included. Below is a summary of the changes.

---

OpensslPkg/RuntimeCryptLib: Fix build issues

UefiRuntimeLib needs to be included in [LibaryClasses] to properly
link the functions. gEfiEventVirtualAddressChangeGuid is missing
in the [Guids] section.

---

generate_cryptodriver.py: Fix migration regression

The migration commit (455ca6b) contained an older section of code in
the DSC generation section. This restores the section to match the
contents in microsoft/mu_basecore#713.

---

Use SHARED_CRYPTO_PATH for the shared crypto path

In CryptoBinPkg, some files (like Crypto.inc.dsc) are used during
the build. This should come from the latest revisions in the
mu_crypto_release repo (which doesn't use the actual binaries).

In consuming repos, the ext dep could be defined anywhere. To
satisfy both of these needs and make the location more portable in
general, a build environment variable is introduced to track the
path.

In mu_crypto_release, the path will be set to "CryptoBinPkg". This
will cause its build to reference the files in the code tree. In
shared crypto consuming repos, it is set in the ext dep (during build)
to the path the binaries are placed in.

---

Add shared crypto Runtime DXE driver

Adds the CryptoRuntimeDxe driver, currently built for IA32 and X64,
it produces the EDK II Crypto protocol backed by runtime code buffers
so the functionality can be invoked at OS runtime.

Consuming RT DXE drivers should link an instance of BaseCryptLib
that is RT DXE compatible, like the RuntimeDxeCryptLib in
CryptoPkg.

RUNTIMEDXE_CRYPTO_SERVICES and RUNTIMEDXE_CRYPTO_ARCH should be set
in platform DSC files to a value other than "NONE" to use the driver.

---

Update readmes for recent changes

Refreshes content in the main repo and shared crypto readme files
to reflect recent changes and current process.

---

• 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, ...
• 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

• Local flavor build and assembly
• Test binaries produced on QemuQ35Pkg and QemuSbsaPkg

Integration Instructions

Use the new Runtime DXE shared crypto binaries if needed for a
platform.