[TECH DEBT] Automate tests for packaging and onedir with optional modules

Description of the tech debt to be addressed, include links and screenshots

In the process of moving to onedir I have encountered countless issues that could easily be caught by testing release packages prior to releasing. Most notably in the first iteration of onedir the usage of curl broke (see #62949) and with relenv the ability to install any modules requiring bundled shared libraries has broken (see #64121 and #64288).

These could all be caught with a test that 1) installs a packaged version of Salt, 2) installs optional dependencies, and 3) tests salt states with those dependencies. At this point these don't even need to be thorough tests; they just need to test that applying a state using one of these modules does not result in a Python runtime error.

There are also some other errors that could similarly be found by running tests on actual packaged environments (such as #64118 and #64157), or in the case of modules with often-changing APIs those optional modules should also be tested (see #58920). However, given all of the changes with onedir I think testing optional modules in an installed package environment should be a first step.

Versions Report

N/A, see linked issues.

Start by tracing how Salt release packages are installed and how optional modules are exercised; the issue does not name specific files or tests. Done means an automated test installs a packaged Salt, installs optional dependencies, and applies representative states without Python runtime errors.