[Fix] depends_on targets can be (NXcoordinate_system) groups

[g5t]

The @depends_on attribute of an entry in a NXtransformations group can be either another entry in an NXtransformations group or a NXcoordinate_system group:

@depends_on: (optional) [NX_CHAR](https://manual.nexusformat.org/nxdl-types.html#nx-char)

    Points to the path of a field defining the axis on which this instance of ...

    Points to the path of a field defining the axis on which this instance of NXtransformations depends or the string “.”. It can also point to an instance of NX_coordinate_system if this transformation depends on it.

    If it is the string “.”, it is explicitly pointing towards the default [NeXus coordinate system](https://manual.nexusformat.org/design.html#the-nexus-coordinate-system).

The NXcoordinate_system group has a depends_on entry not a @depends_on attribute.

This change allows for the target of a transformation's @depends_on attribute to be either a group (with a depends_on entry) or a dataset (with a @depends_on attribute).

[jl-wynen]

@SimonHeybrock can you take a look? I think we should extend this at least to NXcoordinate_system since the standard allows it. But I would prefer to not allow arbitrary classes in depends on chains.

[jl-wynen]

Minor optimisation, probably irrelevant:

Suggested change

	if isinstance(parent, Group) and name in parent:
	target = parent[name][...]
	if isinstance(parent, Group) and (target := ds.get(name)) is not None:
	target = ds[...]

[SimonHeybrock]

@SimonHeybrock can you take a look? I think we should extend this at least to NXcoordinate_system since the standard allows it. But I would prefer to not allow arbitrary classes in depends on chains.

Yes, this should check the NX_class attribute. But even if we do that, this change might not be sufficient, because we are not supporting NXcoordinate_system yet? @g5t is this something you need, or is just having the chain (with potentially broken chain links?) enough?

[g5t]

I'm only using NXcoordinate_system for chaining the transformations at the moment.

My current NeXus structure abuses this implementation to chain through a NXcrystal; and while I like keeping this possibility, I could refactor my implementation to more-strictly comply with the standard.

[SimonHeybrock]

I'm only using NXcoordinate_system for chaining the transformations at the moment.

Are you implying that you don't actually want the NXcoordinate_system represented in the resolved chain, but simply "foward" to the chain within the coord-system?