Support repetition in brush shaders

[nical]

Add support for repeating in the shader rather than decomposing on the CPU.

---

This change is 

[nical]

If we do this we can implement repeating images and gradients much more easily than with CPU-side decomposition. I think that the extra per-fragment cost is small enough that it shouldn't matter for the non-repeated case, while it saves a lot of CPU work in the repeated case. If the extra instructions are really a concern we can probably optimize it some more.
It would also let repeated images and gradients benefit from clipping optimizations that use segments.

Spacing would be implemented on top of this and #2619 using a render task to add the transparent space.

@glennw what do you think?

[glennw]

Yup, I agree, it makes sense to do the repetition here and handle spacing separately.

There's a number of CI test failures - I haven't looked into what causes them yet. We'll also want a try run once those are fixed up.

[nical]

The remaining failure is a sampling artifact when a non-axis-aligned transform is applied due to the inflation of the primitive causing the extra pixels to be on the wrong repetition.

I am looking into addressing this by passing the (equivalent of the) non-inflated local rect to the fragment shader and clamping the uv based on that before the modulo.
It's a bit sad to add an extra varying vec4 for this, but I can't think of a cheaper way right now.

[nical]

The sampling issue due to the aa inflation is fixed. The solution is a little ugly but it doesn't cost anything in the opaque pass and removes the "fail-safe" part in the brush_image shader which was even uglier in the sense that it was removing half of the anti-aliasing shades (making inflation useless). So as a bonus the antialiasing of transformed images looks noticeably better now.

[nical]

Looks like I managed to break another test in the process. Investigating.

[nical]

The remaining issues are fixed.

I suggest reviewing the image part separately from the gradients. The idea is the same but while the gradient shaders both operate in local layout space (-ish), the image shader works in texture space which introduces a few subtle differences (for example an offset to take into account).
The gradient shaders use a strecthed repeated size in layout space (local_rect / repetition), while the image shader scales vUv instead of stretching the rect, achieves the same result but in a way that fits the rest of the shader.

[nical]

r? @glennw

[kvark]

Note: reviewed in #2644

[glennw]

(reviewed in #2644)

[nical]

@bors-servo r=glennw

[bors-servo]

📌 Commit 7ee166a has been approved by glennw

[bors-servo]

⌛ Testing commit 7ee166a with merge 2410227...

[bors-servo]

💔 Test failed - status-taskcluster

[nical]

New reftest failures from outer space :(

[nical]

@glennw looks like this was broken by this code:

webrender/webrender/src/picture.rs

Line 575 in 565e240

request.push(shadow_rect);

from #2656 which writes some data for the drop shadow in the spot where this PR writes the repeat parameter.
I am not sure how this works (the drop shadow hack). I'll have a look tomorrow but if off the top of your head there is a simple way to shift that data by another vec4 and leave the parameter available for repetitions it'd be great.

[nical]

@bors-servo r=glennw

[bors-servo]

📌 Commit a90c04d has been approved by glennw

[bors-servo]

⌛ Testing commit a90c04d with merge b360f8a...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: glennw
Pushing b360f8a to master...