Cache held frames from ImageReader Node

[mrpurest]

Summary

When using the "hold" option on the imageReader node, it will use existing frames to patch missing frames.
However the caching system does not recognise that the same file is being used across multiple frames, and so allot of unnecessary image processing can happen.

User story

What

Using the "hold" option should be just as fast as making a "diy hold" node from a timewarp and an expression.
it would also be good to have a nuke style "nearest" option.

Why

I render sparse frames (eg: 1 frame in 10) in order to get a viewable shot as soon as possible.
Since speed is the primary goal in this scenario, a slow comp process is quite noticeable.

Implementation notes

this was my nearest frame code in python.

if not currentFrame in existingFrames:
nearestFrame = min(existingFrame, key=lambda x:abs(x-currentFrame))