Image memory size: Conditionally use BitmapImage

[chrisglein]

Breaking out a separate sub-section of #2652. As mentioned in the replies there are two parts, the first is restricting the load size (#2863), and the second is this:

After thinking about this and talking it over with @codendone here's what I think we should do:
Only use LoadedImageSurface for repeating images. In this scenario I think we're likely safe just decoding to the image's natural size as it's supposed to tile. We can further optimize this case if necessary.
For all other cases, use a BitmapImage instead, which will give us back the right-size-decoding optimization. There is a fairly significant amount of complexity that we'll get for free if we do this, namely:
a) Right-size-decoding computes the actual size on screen in pixels, which includes all the render transforms in the tree.
b) The size to decode to is computed during the RenderWalk which handles all the weird timing concerns that come up with this (layout has to run first, properties can change multiple times, etc).
b) When the computed size on screen changes, right-size-decoding is smart enough to only decode again if the size gets larger.
Another observation: For images coming from http/https, we're currently downloading the image ourselves into a stream and we're not doing any caching of this stream. This means we'll download/decode/store the same image multiple times if the same URI is used across multiple images.
XAML has caching smarts if we pass the URI into XAML. XAML doesn't fully support all the features needed (such as the authorization header), but we should investigate using the URI in more cases as we'll get caching benefits for free. Alternatively we could do caching ourselves.