Breaking changes being considered for EasyBuild v5.0

EasyBuild v5.0

replacement for LooseVersion (since distutils is deprecated)
- see also https://github.com/easybuilders/easybuild-framework/issues/3963 + https://github.com/easybuilders/easybuild-framework/pull/3794
new implementation of run* functions with cleaner API (w.r.t. returning output/exit code, raises an error for failed commands or not, etc.)
- run + run_qa (vs run_cmd + run_cmd_qa)
deprecate use of True in dependencies to use system toolchain => use SYSTEM instead
enable installing extensions in parallel by default
make Bundle a central concept in framework (instead of a special generic easyblock) (cfr. issue #3403)
rename run method used to install extensions to something better (issue #4113)
don't run sanity check commands from installation directory (issue #4044)

enable by default: download_dep_fail, use_pip, sanity_pip_check
move to PythonBundle rather than PythonPackage even for single Python packages

clean up easyconfigs using PythonPackage or PythonBundle once default for download_dep_fail, use_pip, sanity_pip_check was changed

make sanity_check_commands a required parameter (allow setting it empty)
- could be done only for new PRs, so doesn't necessarily have to be tied to EB v5.0
- a bit silly for library-only easyconfigs...
fix easyconfig parameter consistency, e.g.
- (pre)configopts -> (pre_)configure_options
- postinstallcmds -> post_install_commands
- modextrapaths -> module_extra_paths
let EB automatically try to download the lowercase version of sources if download fails
make all software names lowercase by default
- already possible with custom naming scheme, but making this the default has advantages
- better to implement check in easyconfigs test suite to avoid introducing names with different capatilization
Get rid of moduleclass ec parameter (or at least make it non-obligatory...and maybe deprecated)
- Selection is somewhat random (and subject to change from easyconfig to easyconfig)
  - A lot of software does not easily fall into a single class
- Cannot only use the MODULEPATH of a moduleclass as dependencies are not resolved
- Idea for a replacement
  - categories.yml file for each software package
    - allow multiple categories
    - convince Lmod/Tcl to add good support for this (see https://github.com/TACC/Lmod/pull/600)
    - would allow category modification without a big PR for all package ec's
  - could easily generate initial files from moduleclass and for Lmod use whatis("Category: Tools, Develop") in the module file