Add `build_target` parameter to `PythonPackage`

[Flamefire]

Using buildcmd to pass options to setup.py is confusing and makes it impossible to fully replace the build command. Introduce build_target similar to install_target and deprecate passing a target and optional options via buildcmd.

The old behavior is used when buildcmd is a known setup.py command such as build or build_ext or a single word, e.g. clean.

My first attempt was to only detect buildcmd = '%(python)s ...' as an immediate fix for #3570 but that would limit us to much going forward when a Python package build uses a custom command like ./build_wheel --foo

If this is acceptable I can open an accompanying PR to update the EasyConfigs to replace buildcmd.

[Flamefire]

Current behavior:

1. When use_pip = True (preferred way) then buildcmd is used as a command to run if explicitely set. Usually it does nothing in the build step
2. Otherwise (setup.py) buildcmd is (ab)used as a parameter(s) to python setup.py

So for 1. it works as intended, only 2 is basically broken/unintuitive.

The intention here is:

1. If buildcmd is set it is used as-is
2. Else If use_pip is not set then build_target is used, defaulting to "build" as the parameter to setup.py if use_pip is set then no build command is run
3. To support the current abuse there is logic to detect when buildcmd is set to something intended for setup.py not as a command itself. This is deprecated

The jaxlib easyblock has use_pip=True, defaults buildcmd to build/build.py and will later issue pip install dist/*.whl by just setting install_src

We could have easyblocks implement build_step if required but IMO this would be a lot of boilerplate and one could forget e.g. (pre)buildopts. Additionally, the PythonPackage easyblock captures the output of the buildcmd to detect e.g. downloaded dependencies.
So IMO keeping the buildcmd can be useful.

Maybe: Add build_cmd and deprecate buildcmd. Handle buildcmd as currently done (in the surprising way) but push users of that to build_cmd or build_target. That would be consistent in naming to e.g. ConfigureMake etc., avoid heuristic detection of the intended meaning and give full flexibility when required.

[boegel]

@Flamefire I changed to target branch in this PR from 5.0.x to develop, you should synchronize your PR branch with current develop branch (which has received a massive update after the release of EasyBuild v5.0.0, see https://github.com/easybuilders/easybuild-easyblocks/pull/3670)