Destroy Runner/MasterMinion resources in salt-run and fix MasterMinion.__del__

[twangboy]

What does this PR do?

salt-run left its Runner un-destroy()'d, and RunnerClient / WheelClient never cleaned up the MasterMinion they lazily create via SyncClientMixin.mminion. Both were only reclaimed by __del__'s GC-time safety net, which now logs a loud "unclosed Runner"/ "unclosed MasterMinion" WARNING on every salt-run invocation instead of being silently filtered.

• salt/cli/run.py: wrap SaltRun.run() in try / finally so runner.destroy() always runs, covering both the --doc early-exit and the normal path.
• salt/runner.py, salt/wheel/__init__.py: destroy() now also tears down self._mminion.
• salt/minion.py: MasterMinion.destroy() leaves returners/functions/utils as {}, not None, but __del__'s "already torn down" check tested for None specifically, so even a properly destroy()'d MasterMinion kept tripping the warning. Check falsiness instead.

What issues does this PR fix or reference?

Fixes #70174

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• Docs
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

Yes

[twangboy]

Addressed both considerations:

1. Code duplication in SaltRun.run — checked the diff against 3008.x: this isn't duplication, it's a straight re-indent of the existing body one level deeper under the new try: ... finally: runner.destroy(). Every statement appears exactly once and the nested try/except SaltClientError block is preserved intact. No change needed.

2. MasterMinion.destroy() attribute resets — this one turned up a real gap: destroy()'s per-component teardown calls (returners/functions/utils/states/rend/matchers/executors/proxy/serializers/opts["grains"]) ran back-to-back with no exception isolation, so if any one .destroy() call raised, every later step — including resetting functions/utils to {}, which __del__'s check inspects — was silently skipped, and the exception propagated out of destroy() itself. The same unguarded pattern existed in RunnerClient.destroy()/WheelClient.destroy(), which is sharper: if self.event.destroy() raised, self._mminion.destroy() — this PR's whole fix — would never run. Since destroy() is now called unconditionally from salt/cli/run.py's finally: block, that exception would've replaced SaltRun.run()'s real result with an unrelated traceback.

   Pushed a follow-up commit (6b264b8) that wraps each component's teardown in its own try/except (mirroring the existing pattern in salt/utils/asynchronous.py: SyncWrapper.destroy()) and makes every attribute reset unconditional, so one component failing can never block another's teardown or block destroy() from completing. Added regression tests in test_minion.py, test_runner.py, and wheel/test_init.py covering the "one step raises, the rest still runs" guarantee.