Fix bug with alpha to coverage by enabling depth discard when using alpha to coverage

[clayjohn]

Fixes: #82637

The issue here is that the area of coverage when rendering to the depth prepass was greater than the area of coverage when rendering the object. Leading to unshaded pixels around the edges.

By way of background, what alpha to coverage does is slightly shrink the area of coverage, and in the distance between the regular coverage of alpha hash, and the new area of coverage, it creates a little gradient which uses alpha to coverage to reduce coverage samples and create a smooth transition (as smooth as MSAA can provide anyway).

We do two types of discarding. One when using alpha scissor or alpha hash (alpha scissor is specified by the user, and alpha hash is computed dynamically). And another when using depth_prepass_alpha. In theory, we should never use both. The changes in #79865 made that assumption which is what brings us here. Alpha to coverage needs the depth prepass to use a much smaller coverage value or else it ends up with one bigger than the alpha scissor coverage and that leads us to the current black artifacts.

This PR allows the depth pass to do its discard, even when using alpha hash materials as long as depth_prepass_alpha or alpha to coverage are being used.

Future work

This PR is enough to solve the regression and restore the 4.1.x behaviour. However, the fact that we have to do this is ridiculous. We really need to do a careful re-evaluation of how alpha to coverage is implemented and fix issues like this. For 1, we should be able to get an exact coverage based on the information we have. This approach leaves way too much of the object out of the depth-prepass.

We should go ahead with this PR for 4.2. But for future releases we need to strongly consider making larger changes to improve the feature instead of just fixing the regression.

Dev1

Beta3

This PR

[akien-mga]

Thanks!