Use pixels to store the amount of shift in raster correction

[ecobost]

Right now for raster correction (see background below) we use the temporal fill fraction during scanning (amount of time the laser was on during the scanning of each line) and record the correction as the angle needed to add to the laser beam to correct for the beam shuttering being out of sync. There is no need or benefit for that; it just makes the code more complex and hard to understand. We don't need to care about the physics of the scanning, all we need to know is that the odd rows and even rows may be out of sync and compute the amount of pixels that the odd rows should be shifted[^1] to match the even rows; we get the exact same result with much more interpretable code and quantity (pixel_shift vs raster_phase).
[^1] During the actual correction, we should shift the odd rows half this amount to the left and the even rows half to the right to drop about the same amount of info from either side. This is how it's done right now.

Background

Scanning happens one row at a time in a sigsaw motion; the first row is scanned from left to right then the second is scanned from right to left and so on. The laser shuts off at the end of one line while it stops and reverses direction and turns back on at the start of the new line:

Sometimes the timing of the shutting off and on is out of phase and all odd lines don't align with all the even lines(left). Raster correction solves this(right):