Post binary hooks should support multiple executables

[LDong-Arm]

Description of defect

Currently, post binary hooks we define for CMake can be only run on one executable, which is assumed to be the top-level project (in ${CMAKE_BINARY_DIR}). As we are adding all greentea tests as subdirectories of mbed-os, the hooks need to be able to run once per test.

Target(s) affected by this defect ?

Any target with a post binary hook (e.g. ARM_MUSCA_S1)

Toolchain(s) (name and version) displaying this defect ?

Any

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.13.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Any

How is this defect reproduced ?

Compile a greentea test (e.g. using #14892), and the hook is not run on the binary. For example, a raw binary of the ticker test is ~40KB but a full binary for Musca S1 is ~1MB incl bootloader and TF-M secure binary.

[LDong-Arm]

Because every CMake executable target has its own output binary path, a post build command needs to have the binary path as an argument. Having read as much CMake documentation and tried as many methods I can think of, I've come up with two
different implementations:

• Each Mbed targets (that has post-build operations) defines a function which generates post build commands. The build system calls this function once per executable. (LDong-Arm@4d66bac)
• Each Mbed target (that has post-build operations) defines a post build command template with placeholders. The build system derives a post build command for each executable. (LDong-Arm@a2b3186)

Both work okay, but neither looks simple due to what CMake can do:

• "generator function": It requires an exact function name for all targets (guarded by macros to avoid conflicts), because CMake doesn't support dereferencing a variable into a function name.
• "templates": This involves finding & replacing placeholder texts with real values on the fly.

Please see the commits and messages for details. In short, the challenge is that post build hooks are defined by Mbed targets which are fixed/independent of projects, but they need to take each CMake executable target's binary path as an argument which depends on projects.

@ARMmbed/mbed-os-core What do you think?

[Patater]

Could a CMake file from mbed-os (e.g. app.cmake) provide a function that applications can call and pass in their binary path to?

[LDong-Arm]

After discussing with @Patater and @rwalton-arm, we decided to proceed with the first approach - let Mbed target define a function that generates post-build commands, given a CMake executable target. PR raised to @rwalton-arm's fork for review: rwalton-arm#1. Once merged (actually rebased and fast-forwarded), it'll automatically become part of #14892.