Fix support for Str datatype Enum signals

[DiamondJoseph]

Allows for signals that are backed by enums but have a Signal datatype of str.

e.g. for the Aravis TriggerMode

[Tom-Willemsen]

The code, as far as I understand it, looks fine.

Can we add some documentation about exactly how enums are supported and which combinations of SomeEnum(str, Enum), SomeEnum(Enum) etc are supported?

e.g. some other places seem to believe that str enums are always required. If that's no longer true can we say so in the docs somewhere.

The testing for this is also getting a little bit hard to follow and check that it's really checking all the cases we care about. Maybe out of scope for this issue though.

[DiamondJoseph]

Can we add some documentation about exactly how enums are supported and which combinations of SomeEnum(str, Enum), SomeEnum(Enum) etc are supported?

e.g. some other places seem to believe that str enums are always required. If that's no longer true can we say so in the docs somewhere.

SomeEnum(str, Enum), and str are valid datatypes for a signal with an enumeration as a backend. SomeEnum(int, Enum), SomeEnum(float, Enum), SomeEnum(Enum), float, int etc. are not.

The testing for this is also getting a little bit hard to follow and check that it's really checking all the cases we care about. Maybe out of scope for this issue though.

I think #137 simplifies the tests by making all of the expected descriptors much simpler to generate, I started following it up again today.

[Tom-Willemsen]

SomeEnum(str, Enum), and str are valid datatypes for a signal with an enumeration as a backend. SomeEnum(int, Enum), SomeEnum(float, Enum), SomeEnum(Enum), float, int etc. are not.

Perfect. So where the docs currently talk about using Enum can you add this sort of clarification? Happy for it to be a link to a new/separate docs page if that's easiest. The relationship between datatype and backend probably also could do with explaining for an unfamiliar user.

[coretl]

I'm not convinced that we want to start returning str from SignalRW[Enum].get_value(), which I think this does. Can we leave the enum conversion in, but make it optional? Or make a new converter for it?

[coretl]

Happy to merge when the ordering issue is sorted