[Impeller] HAL: Allow for asymmetrical stencil configuration in Pipelines

[bdero]

Currently, it's only possible to configure the stencil operation symmetrically (for frontfaces and backfaces at the same time), but all of the graphics backends Impeller supports (and will support) allow for differing configuration between frontfaces and backfaces. This can be used for some 3D rendering tricks, like Carmack's Reverse.

Specifically, this would mean adding/renaming stuff in StencilAttachmentDescriptor to allow for configuring the stencil operation separately for frontfaces and backfaces, and then making it work on Metal, OpenGL, and Vulkan.
Before making a decision about how it should look, definitely check out how this works in our backends (like Metal) or other HALs (like WebGPU).

Also, it occurs to me that we don't have anything that just shows off the raw stencil ops working, so it would be nice if we could add something to renderer_unittests.cc that updates the stencil and uses it to clip another draw call, for example.

[johnmccutchan]

Digging into this more it looks like PipelineDescriptor already supports specifying front and back face stencil descriptors already.

PipelineDescriptor& SetStencilAttachmentDescriptors(
      std::optional<StencilAttachmentDescriptor> front_and_back);

  PipelineDescriptor& SetStencilAttachmentDescriptors(
      std::optional<StencilAttachmentDescriptor> front,
      std::optional<StencilAttachmentDescriptor> back);

This also appears to be wired up correctly for the Metal backend but I don't think it is wired up in the Vulkan or GLES backends.

Perhaps we want to rename StencilAttachmentDescriptor to StencilFaceAttachmentDescriptor but I'm not sure if the extra word is really adding that much. I am leaning towards not renaming anything but just fixing the implementation for Vulkan and GLES to do the right thing.

[bdero]

Ah great, yeah fixing up the existing stuff and throwing in a playground test SGTM.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.