Resolve "(viz): refactor transfer function data"

Description

This is a major rework of the transfer function data. Now the transfer function contains is a real piecewise function. Each piece is stored in the data can be individually edited and thus is serialized. Pieces can be accessed and edited independently thanks to the pieces() function that returns a vector of TransferFunctionData. When the pieces are modified, the function mergePieces() must be called to mix the pieces together.

Here is a simplified class diagram of the new data:

 classDiagram
      direction LR
      ContainerWrapper~std::map~  <|-- TransferFunctionData
      TransferFunctionData <|-- TransferFunction
      TransferFunction "1" *-- "N" TransferFunctionData
      class TransferFunctionData{
          sample()
          window()
          level()
          interpolationMode()
          clamped()
      }
      class TransferFunction{
          pieces()
          mergePieces()
      }

This implies that the duplicated sight::module::ui::qt::SMultipleTF and sight::module::viz::scene2d::SMultipleTF are removed in favor of sight::module::ui::qt::STransferFunction and sight::module::viz::scene2d::STransferFunction.

On top of that, the former TF "pool" is no longer exposed anywhere in the services interfaces, thus from the XML. sight::module::ui::qt::STransferFunction handles this "pool", renamed as "presets", internally.

Other changes

• sight::data::TransferFunction::mergePieces() implies the removal of sight::module::data::SMergeTF service. It also brings a functional change, the pieces of the transfer function is performed with an average of colors instead of a strict additive blending.
• It is no longer possible to move a transfer function piece outside the range of the viewport (bug fix request in the comments of this ticket).
• Adjusting the window in the negatoscope is now reflected properly in the transfer function editor (partially fixes #847 (closed))
• Moved and renamed TransferFunctionManager from scene3d to scene2D::TransferFunctionWindow.

Open discussions

• There is no mechanism in the new API to force the update of the transfer function when pieces are modified. The places where this is used and may be used in the future is so limited that I don't think it is worth providing an RAII object for instance to enforce the call to mergePieces().
• In the end, the transfer function is still exposed in the services API. Hiding the transfer function in the image object would add more constraints, so for now, I think it is better to keep it like this
  • inability to display an image twice with two different TF. A workaround would be to copy or shallow copy the image.
  • inability to share a transfer function between two images. A workaround would be to copy the transfer function.

Closes #877 (closed)

How to test it?

• Run SightViewer
• Load an image
• Test extensively all transfer functions features with the editor in the right panel