Make ZAP aware of code driven clusters and update UI accordingly

[andy31415]

Exising logic for code driven clusters is:

• https://github.com/project-chip/connectedhomeip/blob/master/src/app/common/templates/config-data.yaml#L109 contains a list of such clusters, templates are aware of them and do things like "generate no setters if code driven"
• we still add partial "workarounds" for ember-to-codegen integration:
  • we mark codegen-only attributes as "attributeAccessInterfaceAttributes"-only in https://github.com/project-chip/connectedhomeip/blob/master/src/app/zap-templates/zcl/zcl.json#L171 . as a result these will show up as external (or callback in matter files)
  • when defaults are needed from zap, we allow them to be "RAM" in zap

The processing for such defaults is then:

• zap generates endpoint-config with default values
• ember init loads defaults into zap ram buffer
• CodegenIntegration (from code driven clusters) uses ember methods to load from ZAP into instances of code driven cluters

This is generally wasteful resource wise:

• extra RAM because we need ZAP to store defaults in RAM as an intermediate
• extra code, because calling ember functions to load into code driven clusters is needed
• potentially unclear UI (e.g. NVM would have no meaning for these attributes, they are essentially just a "load default from ZAP")

Ideally we would want to be able to communicate to ZAP:

• what clusters are code driven (to have UI about this)
• customize how attributes are set up (e.g. provide or do not provide defaults for them). Hide invalid options (code driven code defines what is/is not supported)
• may want to cusomize "number of dynamic endpoints" since flash optimizations can be done without dynamic endpoints
• provide sufficient configuration/data that one can get "defaults from flash" without requiring a separate RAM buffer in ember. Direct pointers would be useful for strings (so we store the string pointer, not a copy in RAM).
• zap should be able to fetch this information from the codebase - we are updating/creating clusters in the matter SDK, so expect to update any configuration within the matter SDK codebase

To be determined:

• how does one communicate to zap about code driven clusters (we have a yaml now ... is it sufficient? should we change something?)
• how does one communicate how each attribute in handled by code driven clusters (i.e. default-only or internal-only)? We currently use zcl.json however that seems odd as it is named after AAI
• how can we update the endpoint_config generation so that we preserve defaults but do not allocate the extra RAM buffer for the data. What API will be available in ember for "get default value"?