Generate a unique id for every detector element

[KrisThielemans]

We need to be able to generate a unique id for every detector element (from the "tuple" of all ids used to specify it). This currently needs to be done outside of yardl.

More discussion in #22 (comment)

[KrisThielemans]

Also related in #22

We currently include a explicit identifiers (id) in various places. However, these are redundant, as they could just correspond to the number in the list. Remove?

[KrisThielemans]

For clarity, this relates to the detectorIds used at

PETSIRD/model/TripleEvent.yml

Lines 2 to 4 in c5b0e46

	TripleEvent: !record
	fields:
	detectorIds: uint*3

PETSIRD/model/CoincidenceEvent.yml

Lines 3 to 6 in c5b0e46

	CoincidenceEvent: !record
	fields:
	# the pair of detector elements
	detectorIds: uint*2

From #22 (comment) (marginally edited)

Currently, we can iterate through all detecting elements as

PETSIRD/python/petsird_plot_scanner.py

Lines 95 to 106 in c5b0e46

	for rep_module in header.scanner.scanner_geometry.replicated_modules:
	det_el = rep_module.object.detecting_elements
	for mod_transform in rep_module.transforms:
	for rep_volume in det_el:
	for transform in rep_volume.transforms:
	draw_BoxShape(
	ax,
	transform_BoxShape(
	mult_transforms([mod_transform, transform]),
	rep_volume.object.shape,
	),
	)

That could "define" the order. (Having an explicit list of the various [module_type, module_num, det_element, ...] would be possible but tedious).
We could distribute code that constructs a LUT by doing this iteration.

In the previous "data elements" meeting (2024-11-29) we leaned towards adopting this definition (and therefore removing the current lists of ids for every module etc).

[KrisThielemans]

A separate question is then where/how to document this. As the detectorIds are referenced in at least 2 places, we should avoid duplicating that documentation. @rgwells2023 suggests that could be in ScannerInformation. I think it would be better to give a type, with its own documentation, e.g.

% This is the basic type for detector IDs using in `CoincidenceEvent` and `TripleEvent`.
% It is an unsigned integer that runs over all the "crystals". The correspondence between
% this integer and a module/det_el is defined by ...
DetectorID: uint


CoincidenceEvent: !record 
   fields: 
     # the pair of detector elements 
     detectorIds: DetectorID*2
    ...

(obviously, wording, nomenclature (#28) and correspondence TBD)

[sstute1]

Having this unique definition of the global detector ID as a type is a good idea, +1

[KrisThielemans]

Having this unique definition of the global detector ID as a type is a good idea, +1

See #76