Re-segmentation

[Yves Savourel <ysavourel@enlaso.com>]

Hi all,

Thinking more about the different solutions for re-segmentation in 2.0, especially about solution #4:

- We would have to define PRs for the <segment> attributes like translate, approved, state, etc.
Note that translate would logically become a <mrk translate='yes|no'>. Is that mean we should always have this info as an <mrk>?

- We would have to add an id in all top elements like <matches>, <changeTrack> and allow multiple of them at the <unit> level.

- The part that concerns me most is the paradigm shift for developers. Traditionally many tools are segment-based and with solution
#4 they would have to change how many metadata for the segments would be stored, and decide what to do with the parts that don't
correspond to a segment anymore (overlapping <mrk>s and sub-segment <mrk>).

- We may end up with <segment> containing a lot of <mrk> at both ends. It may take some efforts to deal with those. They may have
some side effects on functions like TM matching, etc.

I'm still relatively sure that #4 is probably the better representation on the long-term, but it is a very big change. So the more
feedback before we go that way the better. And we really need examples and working implementation for this.

Cheers,
-yves