Return quite close to original approach for "no colour conversion".

There's a few things going on here:

1. Improve the regression test for 3042.  Previously we made a DCP from
the reporter's _original_ prores file (before they converted it to XYZ)
and compared the result to a reference J2K file of uncertain origin.

This seems wrong because:
a) We never got confirmation from the reporter that the fix worked for
them, so any arbitrary reference is dubious.
b) It doesn't seem to reflect their actual complaint, which was that
they got a different result when making a DCP from XYZ TIFFs compared
to their "XYZ" Prores.

The new test makes a DCP from their TIFFs and "XYZ" Prores and compares
the result.

2. Revert to the old approach to "no conversion" handling.  In the good
old days we did everything -> RGB48LE except XYZ12LE -> XYZ12LE, and
that's what we do again here.

3. Change the YUV->RGB conversion from Rec.601 to Rec.709 for the
"no conversion" case.  This fixes the 3042 regression test.

The supposed "XYZ" Prores is yuv444p12le according to ffprobe.  So I
think what we have here is actually a file that was converted to XYZ
and then back to YUV by Resolve.  I experimented with using the raw
YUV values and considering them as XYZ but this was clearly wrong.

I think 3 is probably what I should have done in the first place.

1 files changed, 1 insertions, 1 deletions

diff --git a/run/tests b/run/tests
index 18be05718..3324b02ab 100755
--- a/run/tests
+++ b/run/tests
@@ -3,7 +3,7 @@
 # e.g. --run_tests=foo
 set -e
 
-PRIVATE_GIT="ddd3a3c138912b4588536c3b0ced7ef816facd12"
+PRIVATE_GIT="5aa4660a36d2aa9c95de8e353b75c9cf29f6b02e"
 
 DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
 source $DIR/environment