Make types in opentime immutable.

[ssteinbach]

For the C++ API, we're looking at making the base opentime types immutable (RationalTime, TimeRange, and TimeTransform).

This also includes a subtle fix to the way that TimeRange is constructed: now if you pass in only one of the two arguments, the other argument will be initialized in the rate of the one you passed in.

[ssteinbach]

@alatdneg you might also be interested in this change.

[codecov-io]

Codecov Report

Merging #372 into master will decrease coverage by 0.11%.
The diff coverage is 91.45%.

@@            Coverage Diff             @@
##           master     #372      +/-   ##
==========================================
- Coverage   87.07%   86.96%   -0.12%     
==========================================
  Files          63       63              
  Lines        5580     5600      +20     
==========================================
+ Hits         4859     4870      +11     
- Misses        721      730       +9

Impacted Files	Coverage Δ
opentimelineio_contrib/adapters/extern_rv.py	0% <0%> (ø)	⬆️
opentimelineio/adapters/cmx_3600.py	91.57% <100%> (+0.01%)	⬆️
opentimelineio/algorithms/stack_algo.py	96.87% <100%> (+0.1%)	⬆️
...neio_contrib/adapters/advanced_authoring_format.py	92.32% <100%> (+0.02%)	⬆️
opentimelineio/core/composition.py	94.35% <100%> (ø)	⬆️
opentimelineio/core/item.py	97.14% <100%> (-0.05%)	⬇️
opentimelineio/algorithms/track_algo.py	94.8% <100%> (ø)	⬆️
opentimelineio/schema/stack.py	90% <100%> (-0.33%)	⬇️
...elineio_contrib/adapters/tests/test_aaf_adapter.py	97.16% <100%> (+0.02%)	⬆️
...imelineio_contrib/adapters/tests/test_rvsession.py	31.42% <50%> (+0.54%)	⬆️
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 74d45be...0541830. Read the comment docs.

[reinecke]

I really like the shift toward immutability on the opentime types, I think it'll make the type feel a lot more like other number types in python and do a good job guarding against unexpected programming errors (especially the iadd use case).

In terms of conforming to float, I think this brings to the front the conversation about data types in RationalTime. That conversation is a bit larger, so I put an analysis over in the group discussion:
https://groups.google.com/d/msg/open-timeline-io/a57pa3-DxEQ/LTVmEkmNBwAJ

[jminor]

@ssteinbach how onerous would it be to split this into two PRs, one that deals with immutability, and one that deals with the float enforcement?

[ssteinbach]

@ssteinbach how onerous would it be to split this into two PRs, one that deals with immutability, and one that deals with the float enforcement?

We could do that. Is that what @reinecke would prefer? My only caveat on that is that there are operations inside OTIO that cast to float - so int-y-ness could get removed anyway. Those come up when you're translating across time rates - if you're using all ints and your time rate is always the same, the addition/subtraction stuff should preserve ints that you put in.

[ssteinbach]

I've rebased to the latest upstream master and removed the cast-to-float. This should be ready to accept.

[alatdneg]

Missed this.. This break a lot of my code, as I do += / -= on RationalTime values.