Resize transform optimization: use swscale when appropriate

[scotts]

When there are no transforms, we use swscale's sw_scale() directly for color conversion, rather than calling filtergraph. This is faster, as we don't pay the startup cost of the much more general filtergraph.

As of #1013, if we have any decoder-native transform, we always use filtergraph. However, if we have exactly one transform, and that transform is a resize, we may be able to just call sw_scale() rather than use filtergraph. However, we will have to call sw_scale() twice:

1. First to convert the frame into the output pixel format and colorspace. We currently only support RGB24.
2. Then to do the resize in RGB24 space.

If we were to call sw_scale() once, then the resize would happen in the input frame's pixel format and colorspace. As of #1013, we take great care to make sure all transforms happen in the output pixel format and colorspace.

This issue has two components:

1. Implement this optimization. We have to make sure we don't unnecessarily call sw_scale() twice when we only need to do a color conversion.
2. Benchmark that this "optimization" is indeed faster than just calling filtergraph. If it is not, then it's not worth checking this implementation in.