Add `zap_clusters_with_custom_implementation` option to `chip_data_model()` template, which allows to list clusters that need to be available in a device, but don't use the standard implementation in `src/app/clusters/<clustername>/<clustername>.cpp`.

# Usage
To exclude a particular cluster's standard implementation in favor of an application level implementation:
- in the BUILD.gn file for the application specific `.zap` file
- in the instantiation of the `chip_data_model` template
- add a variable `zap_clusters_with_custom_implementation`
- assign it a list of strings with cluster names, corresponding to directories in the `src/app/clusters` directory.
- this causes the cluster implementation file(s) not to be included in the build, allowing re-implementation at the application level.

Example, excluding standard implementation of level-control:
```
chip_data_model("zap") {
  zap_file = "myproject.zap"
  zap_clusters_with_custom_implementation = [ "level-control" ]
  zap_pregenerated_dir = "//zap-generated"
}
```

# Background
Some clusters, for example Level Control, are implemented with the assumption of direct low-level access to the device hardware. For bridged devices, the actual interface might be much more high level, as in my case where I have lights which are fully capable of performing parametrized smooth transitions but are NOT capable of receiving output changes in millisecond intervals. In such cases, a cluster might need application-specific re-implementation.

This changeset allows, from the application's ZAP BUILD.gn, to exclude the standard cluster implementation file, allowing re-implementation of the needed ember callbacks in a application specific file outside the connectedhomeip repo.