sec_mem: add note about the perf implications

sec_mem: add note about the perf implications

Testing secure storage for ml-kem/dsa [1] shows performace penalty
when secure storage is enabled.

| Threads | baseline usec/handshake | secmem usec/handshake |
|---------+-------------------------+-----------------------|
|       1 |              586.784756 |            588.306131 |
|       2 |              599.537648 |            601.007393 |
|       4 |              610.663361 |            613.600663 |
|       8 |              649.347376 |            869.693358 |
|      16 |             1176.402781 |           2487.335286 |
|      32 |             2345.594618 |           5155.747515 |
|      64 |             4697.556045 |          11170.627031 |

the test shows that sec mem is ok-ish up to the number of available cores,
and when the sec mem lock gets contended, performance goes down rapidly.
Tested on Apple M4 Pro.

[1] https://github.com/openssl/openssl/pull/27625

Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28011)

(cherry picked from commit b8cc32766060757254f31139d6c521465d796d0d)