CMake: Revise ABACUS executable naming logic

[Growl1234]

The previous implementation enumerated most combinations of LCAO/PW, LibRI, ML, CUDA, and MPI through deeply nested conditionals. This PR instead determines the executable name from two independent components:

• feature: pw, basic, std, ml, or max;
• backend: gpu, para, omp, or ser.

The final name is then constructed as abacus_<feature>_<backend>, like what's provided before.

Changes

• Remove the duplicated nested executable-naming branches.
• Treat CUDA and ROCm builds consistently as gpu.
• Distinguish non-MPI OpenMP builds with the omp suffix instead of classifying them as ser.
• Ensure the executable name is always determined without relying on particular MPI/GPU combinations.
• Remove the unnecessary cache-variable cleanup for ABACUS_BIN_NAME.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Growl1234]

After discussion with @ZhouXY-PKU, the binary names has been revised as below:

abacus_${_abacus_bin_level}_${_abacus_bin_para}(_${_abacus_bin_device})

• _abacus_bin_level contains pw, basic, std, ml, and max, same as before.
• _abacus_bin_para contains para (MPI-parallel), omp, and ser; it means the parallel type of ABACUS will be always exposed via binary name.
• _abacus_bin_device contains gpu, dcu, dsp, and sw; it is only valid and appended when those specified architectures are used.

Most likely this PR can be considered as ready. That being said, I still do not think the current workaround is clean (note I called it "workaround"), therefore it does not resolve #7785. For that issue, my personal wish is to remove this specified binary naming logic and leave just one abacus executable always, as the level part is no longer able to represent the real feature configuration regardless.

[ZhouXY-PKU]

Nice job!, kml can also be added, and para can be omitted?

[Growl1234]

• KML is not a device or architecture essentially; it is an alternative math library (similar to MKL, AOCL) and should not be added into _abacus_bin_device.
• Why omit para? I think no one would expect abacus_std, abacus_std_gpu, abacus_std_omp_gpu.

[ZhouXY-PKU]

• KML is not a device or architecture essentially; it is an alternative math library (similar to MKL, AOCL) and should not be added into _abacus_bin_device.

  • Why omit para? I think no one would expect abacus_std, abacus_std_gpu, abacus_std_omp_gpu.

• I think KML is only supported for HW hardware...(Maybe you can change kml to kunpeng?)
• I think there will be no abacus_std, only abacus(symlink), abacus_std_cpu, abacus_std_gpu, abacus_std_omp_cpu, abacus_std_omp_gpu...

[Growl1234]

There is no _cpu suffix. And omitting para for MPI build wouldn't make binary naming clean.

[Growl1234]

I think KML is only supported for HW hardware...(Maybe you can change kml to kunpeng?)

I think, this does not change "what it is": KML is itself a vendored math library anyways 🤔

[ZhouXY-PKU]

I think KML is only supported for HW hardware...(Maybe you can change kml to kunpeng?)

I think, this does not change "what it is": KML is itself a vendored math library anyways 🤔

But our goal is to make users easier to compile abacus in different levels and platforms (including HW softwares)...

[ZhouXY-PKU]

There is no _cpu suffix. And omitting para for MPI build wouldn't make binary naming clean.

But you can also add one~

[Growl1234]

But our goal is to make users easier to compile abacus in different levels and platforms (including HW softwares)...

Honestly I don't understand why spending time on binary names can make compilation easier... These are totally two different things.

[Growl1234]

And, making the parallelism suffix "optional" makes the naming slightly irregular: for MPI builds, the platform field effectively takes the place where the parallelism field would otherwise be 🤔