Does `AlphaMode::Opaque` carry its weight?

In https://github.com/rust-windowing/softbuffer/pull/321, I added AlphaMode::Opaque as a sort of workaround for not all platforms supporting a mode where the alpha channel is ignored.

Specifically:

• On macOS/iOS with IOSurface, only premultiplied surfaces are supported.
• On Web, both pre- and postmultiplied can be supported zero-copy, but ignored cannot.

Another way to model this would be:

#[derive(Default)]
pub enum AlphaMode {
    #[cfg_attr(not(any(target_vendor = "apple", target_family = "wasm")), default)]
    Ignored,
    #[cfg_attr(target_vendor = "apple", default)]
    Premultiplied,
    #[cfg_attr(target_family = "wasm", default)]
    Postmultiplied,
}

Is there a strong benefit to having a separate AlphaMode::Opaque? We use it currently for debug-asserting that the alpha channel is 1.0, to help with writing cross-platform code, but is that enough of an argument? Is it useful for setting properties like CALayer.setOpaque(true) or { alpha: false } in canvas.getContext?

I guess it may be useful for https://github.com/rust-windowing/softbuffer/issues/211?

Start by reviewing the AlphaMode API and the behavior described in pull request 321. Compare the macOS/iOS IOSurface and Web canvas constraints, including the possible CALayer and canvas alpha settings, and check issue 211 for related requirements. Done means reaching a documented decision on whether Opaque should remain a separate mode.