Add make build system in tf-psa-crypto directory

[ronald-cron-arm]

Suggested enhancement

In preparation of the split, add a make build system to build the crypto library, the PSA programs and the crypto test suites in the tf-psa-crypto directory. It should be an adaptation of the Mbed TLS make build system to the crypto code in tf-psa-crypto directory: one Makefile in tf-psa-crypto, tf-psa-crypto/core, tf-psa-crypto/programs, tf-psa-crypto/tests. In this issue no change to the mbedtls make build system.

Depends on #9261, #9262, #9263, #9266 and #9267.

DoD:
. make (all|no_test|programs|lib|tests|clean|test|check|generated_files|neat) run successfully with a similar outcome as for the whole mbedtls repo.
. make (apidoc|apidoc_clean|lcov|cscope|install|uninstall) not in scope of this issue.

Justification

Mbed TLS needs this for the repo split.

[gilles-peskine-arm]

So the big question: are we splitting the existing makefiles, or creating new ones from scratch? And if new ones, how?

[ronald-cron-arm]

So the big question: are we splitting the existing makefiles, or creating new ones from scratch? And if new ones, how?

I am proposing a middle-ground solution in this issue: we adapt the makefiles we have in mbedtls to tf-psa-crypto code (and we do not change the mbedtls ones in this issue, mbedtls build systems using tf-psa-crypto build systems would be done later as part of another issue and eventually it will be a split of the existing makefiles). That way we should end up with a make build system for tf-psa-crypto similar to the one we have for mbedtls and the work and reviews should not be too complicated. Here I try to eventually split the build systems, not change/improve what we have.

Another way to say it: the proposal is to eventually split the existing makefiles but this issue is just a first step.

[gilles-peskine-arm]

I'm not sure about “should not be too complicated”. Our existing makefiles are pretty complex and error-prone. They're also error-prone in day-to-day work because they don't have correct dependencies. I am not convinced that a clean-slate approach would be slower. And we don't even have to start from a clean slate, since I've offered a cleaned-up version of an implementation that has been working well for one user for several years.