WIP: Logical vs dmx channels

[j-mutter]

This is very much still a work in progress, but wanted to get some more eyes on it before going much further.

This PR implements a new hierarchical channel structure that more closely follows the GDTF spec, ie, where logical channels are defined below physical DMX channels.

Also enables split-channel functionality:

SubFixtureChannel (and thus FixtureTypeChannel) are still the main interface for writing attribute values, but they now act as logical channels and the DMX resolution/output happens one step further down the stack.

Key Changes

Fixture definitions:

• Added FixtureTypeDMXChannel representing raw fixture DMX channels
• FixtureTypeChannel objects are nested under FixtureTypeDMXChannels as logical channels, and can be assigned to specific ranges within the DMXChannel. Split channels work as expected, but currently only for 8bit channels

Fixture instances:

• SubFixtureChannels now register with a parent FixtureDMXChannel and no longer directly write to patched outputs
• FixtureDMXChannel resolves which logical channel should drive the output, and maps the logical value to the raw DMX value and writes it to the patch

Channel Resolution:

• Currently uses the logical channel with the highest DMX range and an active value, essentially HTP but based on the underlying range, not the value.

TODOs

• Backwards compatibility, import/export
• Better UI: range validation?, better naming? (DMX Channel > Channels > Channel is a bit awkward. Maybe the logical channels become "Attribute"s or "Function"s like in GDTF)
• highlight should technically live on the DMXChannel now, currently if you set a highlight = 1.0 on a split channel, it will get mapped within the range and won't use 255 for example. This is solvable, I just didn't get to it yet.
• channel auto-renaming is overwriting things, need to fix.