let CMakeMake remove 'easybuild_obj' build directory if it already exists

[Flamefire]

without also ensuring that the directories that are used for that build are also unique
there are build problems with bundles that contain more than one CMake package and didn’t
explicitly set separate_build_dir to false

This also applies partially to multiple iterations of the same software build (e.g. configopts)

Reported in #1933 (comment)

As the build directory is unique to EasyBuild it is safe to remove

[Flamefire]

@boegel
Analysis of solutions:

1. Remove build directory if exists: Impossible to inspect build files after another package reused it, e.g in bundles. But this is rare
2. Use random name: Breaks ECs relying on easybuild_obj
3. Encode name and other things (e.g. version) into the folder: Breaks ECs relying on easybuild_obj as the name, see let CMakeMake remove 'easybuild_obj' build directory if it already exists #2032 (comment)
4. Add add an additional EC parameter: unique_build_dir. It will start with %(builddir)s/build_%(name)s and append increasing numbers until it finds one that doesn't exist yet. We don't need to append the version number as you won't build 2 softwares with the same name in 1 Bundle, will you? I don't know how to get the current iteration number but the above will "usually" correlate well enough with the iteration number.
5. Build in subfolder of the source directory: Usually done in "generic workflow": mkdir build && cd build; cmake .. <other opts>; make && make install, but also breaks existing ECs, can lead to long folder names and folder must be unique to (but could be easybuild_obj which should be unique enough)

Edit: Current best option: use a named and numbered unique folder. Check easybuild_version if this can be always done, else check EC if easybuild_obj appears in it, if yes fall back to removal of build directory if exist

[boegel]

Merging this for inclusion in EasyBuild v4.2.1.

As discussed with @Flamefire, this improves the current situation (it fixes some use cases), even though it may not be perfect and cover every possible use case.

We can follow up in another PR (cfr. #2036 (comment)).