Scaling bug fix (issue 353)

[MikeIndiaAlpha]

So to be honest I failed to understand completely original author's intentions. It is a complex code, and getting resolutions/aspects right is notoriously tricky. BTDT. Also, this is my last week, and I don't be there to take care of debugging in case of problems.

Here is what I did, then:

1. Resolution is always rounded up to the nearest even number. This is no-brainer, because h.264 doesn't allow for odd resolutions and I think most codecs (at least using "420" style chroma subsampling) won't, either.
2. I noticed that resolution altering logic is applied always, regardless of need. So to avoid screwing up original code I simply added bail out condition - no need to change resolution if it is "valid", that is, if it lies within the encoder limits. This guarantees that all the resolutions (very wide spectrum) that encoder is OK with won't be changed at all.

I hope this is acceptable.

[MikeIndiaAlpha]

Unfortunately I am running out of time here. In my opinion the problem is that existing code changes the resolutions even if they are in the "legal" range - but that allows some tests to succeed. I fixed a few of those but not all. So I guess somebody else has to do it.

Alternative option is just adopt "rounding up to the nearest even number" from my first commit, this will eradicate green bars and everything else should work - only then the problem with changing the resolutions in the legal range will remain.