Use soft references (instead of direct references) to hold on to data loaded
from file references. This should allow images that are loaded to be cached
as long as possible, but freed when available memory gets low.

Pros: If you have lots of huge photos or logos, they should be loaded,
scaled correctly, and only the scaled versions cached. The originals will
be kept in memory as long as possible in case we need other resolutions of
them, but they will be thrown out if memory gets low.
Memory use will be much better when images are only used once / at one
resolution.

Cons: If we have different presentations that use the same image over time,
there will likely be less caching, and initial (re)load for each presentation
will be slower.

I tested with a similar change several years ago and the results weren't great:
most of the images we were using weren't huge, but the performance of loading
and creating Java images for them (on HDDs) was slow, so the best tradeoff for
smooth UI was almost always 'just use a bit more memory' and cache them in memory.

With faster SSDs and CPU but photos often > 4k the balance seems to have
shifted: with this change I sometimes see images being reloaded that would have
been cached before, but memory use is more consistent / less spikey, and the
cache doesn't grow indefinitely (until all file references have been loaded -
which is potentially a lot).

Should help with icpctools#1133, and avoid out of memory errors in cases where we slowly
iterate through all images in a contest package.