Make whitelist_modules only apply to remote dispatch (3006.x)

[dwoz]

Closes #69983 (3006.x backport of #69974)

What this changes

Splits the minion module loader into two views of the same set of modules:

• An outer, whitelist-filtered loader used for wire dispatch. A minion
  with whitelist_modules: [test, mycompany, saltutil] will refuse a
  remote publish of any module not in that list.
• An inner, unfiltered loader that is packed as __salt__ inside every
  loaded module. So mycompany.deploy can still do __salt__["cmd.run"](...)
  internally even when cmd is off the whitelist.

Combined with the existing per-command cmd_blacklist_glob, this gives a
useful defense-in-depth story for minions that do not fully trust the master.

Adjacent fix

salt/modules/saltcheck.py: moves __context__["global_scheck"] = None
out of module-level code and into __init__(opts) with setdefault.
The old pattern re-ran on every exec_module and clobbered state a
running function had already set -- exposed by the two-loader work
above, but a pre-existing violation of the check-then-populate pattern
the developing-modules docs prescribe.

Differences from #69974 (3008.x)

• No optsdict.py proxy-cache change: 3006.x does not have that module.
• No pillar kwarg in minion_mods(): not on this branch.

Otherwise semantically equivalent.

Historical context

• Disabling cmd module causes connection error to master #52592 (2019) and Disabling CMD module on minion #25854 (2015) both closed with "many parts of Salt use
  the cmd module, you cannot disable it" -- this PR removes that constraint
  for the whitelist path.
• Whitelist for bluecoat (reverse of disable_modules support) #35609 (2016) was the original ask that led to whitelist_modules; this
  PR delivers what that feature was supposed to do.