Do we want a `SurfaceConfiguration` builder?

In https://github.com/rust-windowing/softbuffer/pull/321, I've added Surface::configure that takes width, height and AlphaMode. This is necessary because changing those properties requires re-creating the underlying buffers, which is costly, and as such you'll want to do it at once (instead of e.g. having set_width/set_height/set_alpha_mode that each re-creates the buffers).

https://github.com/rust-windowing/softbuffer/pull/317 will add PixelFormat to that as well, and any solution of https://github.com/rust-windowing/softbuffer/issues/29 is probably going to require at least one more parameter. https://github.com/rust-windowing/softbuffer/pull/320 might be in this category as well, I'm a bit unsure.

Do we want to introduce a SurfaceConfiguration struct to help with this, similar to wgpu's? That would allow more easily falling back to default values for parameters that the user doesn't care about:

surface.configure(SurfaceConfiguration {
    width: NonZero::new(width).unwrap(),
    height: NonZero::new(height).unwrap(),
    alpha_mode: AlphaMode::Premultiplied,
    .. // rest is default
})?;

An alternative would be to make configuration happen internally in next_buffer, something like:

impl Surface<'_> {
    pub fn set_size(width: NonZero<u32>, height: NonZero<u32>) /* does not return an error */ {
         self.width = Some(width);
         self.height = Some(height);
    }

    pub fn set_alpha_mode(alpha_mode: AlphaMode) {
        self.alpha_mode = alpha_mode;
    }

    pub fn set_pixel_format(pixel_format: PixelFormat) {
        self.pixel_format = pixel_format;
    }

    // ...

    pub fn next_buffer(&mut self) -> Result<Buffer<'_>, SoftbufferError> {
        let width = self.width.expect("must set width before calling `buffer_mut`");
        let height = self.height.expect("must set height before calling `buffer_mut`");
        self.inner.configure(width, height, self.alpha_mode, self.pixel_format, ...)?;
        self.inner.buffer_mut()
    }
}

This is already what the Wayland backend does internally, so might help make things more cross-platform? Or maybe there are disadvantages to this that I'm not seeing? E.g. maybe resizing in WindowEvent::Resized might help to reduce latency (it could probably be scheduled such that there was a little bit extra time to resize the buffers before WindowEvent::RequestedRedraw)? Creating an IOSurface that fills the screen seems to take anywhere between 30µs and 500µs.

Wrt. error handling, there's probably value in separating the "configure" errors from the "get buffer" errors.

Start by reading the proposed Surface::configure API and the alternatives around next_buffer, then review PRs 321, 317, and 320 plus issue 29 for the pending configuration parameters. Compare the trade-offs for batching reconfiguration, error handling, resizing latency, and cross-platform behavior. Done means reaching an agreed API direction and defining the implementation scope.