RGBGFX can't use input slice without deduplication

[Quinn]

Invoking RGBGFX with an input slice and without deduplication fails assert(remainingTiles == 0) here.

The issue is that the initial value of remainingTiles doesn't account for the reduced number of tiles due to the input slice being set. The tiles visitor does use the correct count, so the loop would exit "early", with remainingTiles > 0.

A simple fix is to just start with the number of tiles in the slice if one is set, otherwise default to use the whole image size as it currently does. This works, but otherwise seems like a low quality fix:

• remainingTiles seems to only be for dealing with the trim option? Doing more with it seems to be moving in the wrong direction.
• remainingTiles & visitAsTiles are both doing the 'how many tiles' calculation/logic which is not good and this duplication is seemingly to blame for the issue.
• The tile visitor/iterator should have a known length and could be trimmed (ended early) based on that -- which appears to be more or less what the 'optimised' (deduplicated) path does.
• If visitAsTiles accessing the options is OK (it currently does), it could just check trim as well.

[Eldred Habert]

Doesn't a lack of slice default it to the image's size? I feel like we shouldn't need to have two branches here, since we should be able to have a unified "area we're going to process" at some point..?