Switch to using zcl_struct_items_by_struct_and_cluster_name in templates.

[bzbarsky-apple]

Our existing uses of zcl_struct_items_by_struct_name were broken if two different clusters used structs with the same name: we would end up enumerating all the struct fields from both structs in a bunch of places.

The fix is to use zcl_struct_items_by_struct_and_cluster_name, which takes as input the struct name and the cluster name.

No visible codegen changes for now, because we have no such name collisions so far, due to it leading to incorrect codegen. Instead we have been working around it by having our naming not match the spec.

This required a few changes other than just the change of helper:

1. The valueEquals in chip-tool did not use to take a cluster name. That needed to be added, and threaded through the call-chain from the place where a cluster name is available, as well as through the recursive invocations of valueEquals.
2. In the java codegen, the cluster name being passed in to encode_value and decode_value was the already-upper-camel-cased version, which does not work as input to zcl_struct_items_by_struct_and_cluster_name. Callsites were changed to pass in the raw cluster name, and actual uses of the name were changed to asUpperCamelCase as needed.
3. While testing, using actual name collisions, a bug was found in the Python codegen: the id of the command being processed was being used when the id of the cluster was intended.

[github-actions]

PR #26226: Size comparison from 05d79a2 to 4553ee0

Decreases (1 build for cc32xx)

platform	target	config	section	05d79a2	4553ee0	change	% change
cc32xx	lock	CC3235SF_LAUNCHXL	.debug_info	20330830	20330829	-1	-0.0

Full report (1 build for cc32xx)

platform	target	config	section	05d79a2	4553ee0	change	% change
cc32xx	lock	CC3235SF_LAUNCHXL		0	0	0	0.0
			(read only)	643249	643249	0	0.0
			(read/write)	203848	203848	0	0.0
			.ARM.attributes	44	44	0	0.0
			.ARM.exidx	8	8	0	0.0
			.bss	197248	197248	0	0.0
			.comment	194	194	0	0.0
			.data	1480	1480	0	0.0
			.debug_abbrev	933224	933224	0	0.0
			.debug_aranges	87792	87792	0	0.0
			.debug_frame	302140	302140	0	0.0
			.debug_info	20330830	20330829	-1	-0.0
			.debug_line	2687904	2687904	0	0.0
			.debug_loc	2838960	2838960	0	0.0
			.debug_ranges	288072	288072	0	0.0
			.debug_str	3042335	3042335	0	0.0
			.ramVecs	780	780	0	0.0
			.resetVecs	64	64	0	0.0
			.rodata	104401	104401	0	0.0
			.shstrtab	232	232	0	0.0
			.stab	204	204	0	0.0
			.stabstr	441	441	0	0.0
			.stack	2048	2048	0	0.0
			.strtab	377963	377963	0	0.0
			.symtab	256976	256976	0	0.0
			.text	536728	536728	0	0.0