Editor: add allow_cmv4_transfer option for experimental CMv4.0 → CMv2.9 level transfer

[bbeny123]

This MR adds an experimental allow_cmv4_transfer option to the editor command.

When enabled, it allows transferring CM v4.0 levels to a CM v2.9 RPU.
Internally, the input RPU is implicitly converted to CM v4.0 (with only a default L254 added).

The option is explicitly marked as experimental.

It is intended strictly for advanced hybrid workflows, such as:

• injecting CM v4.0 metadata into a CM v2.9 RPU (e.g., for Blu-ray-based hybrid RPUs),
• simplifying current multi-step hybrid generation pipelines — for example, in Dovi Scripts, where a modified dovi_tool 1.5.3 performs convert_to_cmv4 before a newer dovi_tool transfers levels.

[quietvoid]

IMO there's no need to add a setting for it.
If someone tries adding CM v4.0 levels to a 2.9 RPU, it should do it implicitly.

[bbeny123]

IMO there's no need to add a setting for it. If someone tries adding CM v4.0 levels to a 2.9 RPU, it should do it implicitly.

Currently, this is only possible using older versions of dovi_tool — newer versions no longer support this behavior.

The allow_cmv4_transfer flag ensures that CM v4.0 conversion doesn’t happen accidentally. It only triggers when the source RPU is already CM v4.0 and the requested rpu_levels include CM v4.0-specific levels. Without both conditions, nothing changes.

[quietvoid]

What's wrong with implicitly converting the RPU to 4.0?
In the end if some transferred levels are 4.0, the intent seems pretty clear to me.

[bbeny123]

There’s nothing wrong with implicitly converting to CM v4.0 — it’s just not supported by the current version, which forces users to rely on the older one. Additionally, the official 1.5.3 version adds default L9 and L11 alongside L254.

Reintroducing convert_to_cmv4 would be sufficient, but on the other hand, why not enable a simpler workflow with just one run instead of two?

[quietvoid]

Ok, I don't think going back to convert_to_cmv4 is an option because it's incorrect by itself.
I guess your solution is correct with the warning.

[quietvoid]

Seems fine to me.