Comments made on an interdiff of a newly-added file rendered only the right-hand side of the diff, instead of both sides. The comment fragment template decided between the one-column and two-column layouts using `comment.filediff.is_new`, which is simply a check for a source revision of `PRE_CREATION`. For interdiffs, that's the wrong thing to check. A file added in one revision and then modified in the next has both an original and a modified side when shown as an interdiff, and both must be rendered. The same is true when showing a file relative to a base commit. The diff viewer got this right, using the computed `is_new_file` state from `get_diff_files()`, which factors in the interfilediff and the base filediff. The comment fragment template was never updated to match, so the two diverged. I've split that out into a `get_is_new_file()` helper, which both `get_diff_files()` and the comment fragment code call, so these now use the same logic. The chunk generator was already producing correct interdiff chunks with both sides populated. Only the template was discarding the original side. Two colspans in the comment fragment template were hard-coded to 3, spanning four columns of a two-column table when rendering a genuinely new file. These are now computed like the others. The colspan calculations were also switched over to the `yesno` filter, matching what we do in other templates. Since review e-mails share this code, comment fragments in e-mail were affected by all of this as well. Testing Done: - Manually reproduced the bug and verified the fix. - Ran unit tests.