Fixes to dimension indices

[CPBridge]

This PR fixes a few known issues with the way highdicom deals with the dimension indices in the Segmentation Image IOD. The following changes are implemented:

• Dimension Organization UIDs are now created for every segmentation image, rather than the old, incorrect behaviour of using a fixed literal UID for every instance highdicom creates.
• A fix to the way dimension index values are calculated: previously this was wrong if there were empty frames in the segmentation pixel array
• In order to make the above fix, it was necessary to remove the add_segments() method of the Segmentation class because information about all segments is required when the instance is created in order to correctly calculate the dimension index value for every segment. To make this possible, the constructor can now accept a 4D array, where multiple segments (that would have previously been added sequentially via add_segments) may be concatenated along the fourth (final) dimension. This has a nice side effect of bringing the constructor in line with the "decoding" behaviour in Segmentation Parsing #74, which returns 4D arrays with the same interpretation.
• An option to turn off the behaviour that omits empty frames from the segmentation image was added
• More unit tests to ensure that the dimension index values are correct

[CPBridge]

Also added a release notes page to the docs that should guide users through the backwards-incompatible removal of add_segments. Calling add_segments now raises a deprecation error pointing to that page

[hackermd]

Thanks @CPBridge. Looks nice! The constructor has become quite a beast now and I am wondering whether we could factor some of the code out into separate methods. It's tricky because instance attributes are being set all over the place, but some parts could probably be separated into functions with no (or only very few) side effects. What do you think?

[CPBridge]

@hackermd I have moved some of the low hanging fruit to methods, unfortunately I don't think there's much more that can be done without passing huge parameter list around

[hackermd]

@hackermd I have moved some of the low hanging fruit to methods, unfortunately I don't think there's much more that can be done without passing huge parameter list around

Yeah, I also found this difficult on other classes. The changes that you've made are nice. The constructor has already lost quite a bit of weight.

[hackermd]

Looks very! Thanks @CPBridge. I only have one minor additional suggestion.