docs: refactor and enhance security framework API documentation

Bring security.md in line with the openvela API documentation standard
and cover the full public surface of the security framework.

Structure changes:
  - Remove all Chinese/Arabic numeric prefixes from headings ('一、',
    '二、', '1、', etc.)
  - Flatten the three-level '## > ### > ####' nesting in favor of the
    standard '## group > ### api' layout
  - Add '## openvela 实现说明' section (REE/TEE split, rpmsg channel,
    API layering, rootkey flow)
  - Add header include declaration

CA application-layer APIs (24 in 5 groups) rewritten as individual
'### function' entries, each with signature, Chinese description,
**参数** list and **返回值** section:
  - Secure Storage (SST):   5 APIs from comsst_ca_api.h
  - Triad (DID + Key):      5 APIs from triad_ca_api.h
  - WeChat Pay CA:          4 APIs from wxcodepay_ca_api.h
  - Alipay CA:              4 APIs from alipay_ca_api.h
  - PIN CA:                 6 APIs from pin_ca_api.h

MiTEE Rootkey section rewritten with proper signature blocks and
parameter descriptions for the read (boardctl BOARDIOC_UNIQUEKEY) and
write (rootkey_provision) flows.

GP TEE Client API:
  - Clean up signatures (remove embedded Doxygen-style comment blocks
    that were inconsistent with the rest of the document)
  - Translate all parameter and return-value descriptions to Chinese
  - Add two missing public APIs: TEEC_RegisterSharedMemory and
    TEEC_RequestCancellation
  - Coverage: 9 / 9 against OP-TEE <tee_client_api.h>

GP TEE Internal API:
  - Keep the status-reference table format (openvela implementation
    status vs. GP specification), but add an opening paragraph that
    points readers to the GlobalPlatform TEE Internal Core API
    Specification v1.3.1 and <tee_internal_api.h> for authoritative
    signature and semantics
  - Clarify the meaning of the '支持' and '实现不完整' status labels

Every CA and TEEC signature in the document has been verified against
the corresponding source header.

Author: tanghao-xiaomi