Several tests fail locally under user environment with customized keyboard shortcuts due to relying on hardcoded keybindings

[CAM-Gerlach]

Description of your problem

As discussed in PR #6044 , in a number of tests of the Spyder test suite, including the very first non-skipped test on Windows, keybindings (using Qt.Key_XXX) are used to activate certain routines (pylint, run file, etc) which are hardcoded to the defaults (affects static_analysis, dedicated_console, and several skipped checks). This prevents me or anyone with custom shortcuts from running the tests at all past the first one, as that one (dedicated_console) fals due to this issue (due to the -x option in runtests.py), at least without one of a few tedious and time consuming workarounds every time. Personally, I'm not a huge fan of many of the default shortcuts and use a heavily customized scheme harmonized between several different IDEs, editors and machines, so just using the stock ones all the time isn't really an efficient option.

Possible solutions would be to either call the routines directly without going through the keybindings, read the actual keybindings from the config file and use those, or (probably best for the general case, as it could solve/prevent other possible test failures due to a non-default config) have the tests run themselves with a clean config file, e.g. temporarily write and restore it, or otherwise telling the tested copy of Spyder to use a clean config. Longer term, probably project-based or at least overridable config files are the answer, but as of now this is preventing anyone with non default shortcuts from running the tests without backing up, wiping and restoring their config files every time, so a straightforward and effective fix is ideal.

Therefore, as I am newer to this whole thing, I was hoping to get the rest of the team's feedback on what's the simplest and cleanest overall method to address this (either those mentioned above or something better I hadn't immediately thought of), and how to approach/structure it. Thanks!

What steps will reproduce the problem?

1. Set a relevant shortcut (run file, run pylint, etc) to something other than the default
2. Run the test suite (e.g. with python runtests.py)
3. Observe failure

What is the expected output? What do you see instead?
Expected: Tests do not depend on user shortcut configuration. Actual: Tests do, and fail if changed.

[CAM-Gerlach]

Thanks @ccordoba12 !