v0.12.1

Fixed

• powershell.instructions.md "InModuleScope Placement" contradicted itself. It said a wrapping
  InModuleScope "forces the module to load during discovery", then said eleven lines later that
  InModuleScope "requires the module to be loaded already - otherwise the test fails with
  No modules named 'X' are currently loaded". Both cannot hold, and the first misstates the
  mechanism: a top-level InModuleScope is file-scope code, so it runs during discovery, and
  because it needs an already-loaded module the Import-Module satisfying it has to sit at file
  scope too, where that import is what actually runs at discovery on every file. Rewrote the
  paragraph and the "Bad" example comment to describe that chain
• powershell.instructions.md "Pester Version Pinning" stated an unconditional "never pin Pester
  to an exact version", which condemns a deliberate side-by-side compatibility matrix. A
  repository verifying its code against more than one Pester major pins those versions on purpose,
  in a manifest that is installed but never imported, and selects one explicitly inside a separate
  process -- autoloading never competes with that pin, because a version is already imported by
  the time discovery runs. Scoped the rule to the Pester version the suite itself runs on,
  and documented the install-only matrix as the exception. Surfaced during the 0.12.0 sync of
  psake/PowerShellBuild, whose requirements.pester-matrix.psd1 is exactly this case
• powershell.instructions.md used the contraction It's where the possessive was meant, in the
  -ForEach binding example comment