* override Electron pop up dialogue to display Generate button correcty.

* fix Studio integration debug logging

* REST api, "/dirtyFlag", for getting user session's dirty flag.

* test rendererAPI's file open function in Cypress

* single build target for easier mac dev flow

https://github.com/project-chip/zap/issues/514

0. Bring in an external single-instance package, that is not electron specific.
1. Add a util method.
2. Converge both headless and UI startup through the same logic.

Honor JENKINS_HOME or --jenkins argument

Several UI issues and minor improvements

BUG: ZAPP-878

open

Calculating the attribute sizes correctly based on whether the attributes being enabled are either singleton or external
JIRA: ZAPP-783

This reverts commit 47d5e7a89c68851cd8e4521953cd975c4f26a96e.

Adding a is_command_default_response_disabled along with is_command_default_response_enabled for convenience
JIRA: ZAPP-797

JIRa: ZAPP-797

Cleaning up the helper and schema based on enabled default response instead of disabled default reponse
JIRA: ZAPP-797

JIRA: ZAPP-797

Adding DISABLE_DEFAULT_RESPONSE to the backend during loading and also adding to the helpers queries such that it can be used for generation

- Adding DISABLE_DEFAULT_RESPONSE to db-mapping
- Adding the above to query-command, query-loader and zcl-loader-silabs for loading into the backend and for querying it from the backend
- Adding changes to the schema to include this in the command table
- Adding is_command_default_response_disabled helper to check if the command default reponse is diabled or not
- JIRA: ZAPP-797

JSON.stringify() does not handle "Error" class properly and just returns a blank {}

* align command/attribute states if an endpoint's newly enabled Cluster is enabled on another endpoint as well.
* refactor naming
* remove useless import.
* clean up deprecated shareConfigsAcrossEndpoints flag via ZAPP-715
* unit test for zigbee flag existing in gen-template file.
* unit test for verifying Attribute Reporting tab being copied across endpoints

BUG: ZAPP-715

JIRA: ZAPP-794

Making changes to an attribute query such that only reporting config default is generated for singleton attributes. Adding tests for the same using one of the existing zap files
JIRA: ZAPP-794

JIRA: ZAPP-757

JIRA: ZAPP-757

JIRa: ZAPP-757

JIRA: ZAPP-757

Making sure that the Zigbee pro templates are backwards compatible with our old zap-type.zapt template for enum generation
JIRA: ZAPP-757

* https://github.com/project-chip/zap/issues/316
* https://github.com/project-chip/zap/issues/423

* https://github.com/project-chip/zap/issues/503
* https://github.com/project-chip/zap/issues/505
* https://github.com/project-chip/zap/issues/507

We were claiming a command is "incoming" or "outgoing" even if it was
not enabled, if it was mandatory.

This led consumers that looked at that state to be out of sync with
other consumers that just looked at the actual enabled state.

This PR makes sure we treat the actual enabled state, not theoretical
mandatory-or-not status, as the source of truth.

We had earlier some 6 months old "Matter test data", that was mostly Zigbee test data with a single CHIP cluster.
Matter had gone far ahead, and people who were just working with zap, without access to main Matter SDK repo,
were only testing with old data. So this updates all the metafiles for Matter and patches the unit tests to
reflect that.

We were creating nonsense mask values (like setting "incoming_server"
for an optional server-generated command if "incoming" happened to be
set in the .zap file for some reason for the server cluster side).

Github#510