layout/stack: opt-in Stack::fit_content() so a wrapping container can adopt the stack's intrinsic size

`Stack::preferred_size` unconditionally reported `(max_width, max_h)` — every stack claimed the full width its parent offered, regardless of what its children actually needed. That is the right default for a FrameLayout-style overlay (the existing callers all rely on it) but it makes the natural "pin a stack to a fixed-size child (e.g. a spacer of `card_w × card_h`) and centre other children on top of it" pattern impossible: a container wrapping such a stack always inherited the full parent width and ignored the spacer's footprint. The new `Stack::fit_content()` builder mirrors the `Column::fit_content` flag — when set, `preferred_size` returns the max of children's intrinsic widths and heights instead of claiming the parent's `max_width`, with the same "skip filler widgets that themselves claim `max_width`" exclusion list (`Spacer` with no `fixed_width`, `Separator`, `Scroll`, `ProgressBar`, `Slider`, `TextEdit` without `fixed_width`) so the flag is not defeated by a flexible child slipping into the stack. Default behaviour is unchanged.

src/layout/stack.rs

@@ -54,6 +54,8 @@ pub struct Stack<Msg: Clone>
 	/// Children with their alignment, margin, and extra `(x, y)` translation
 	/// applied after alignment. Drawn in order — last child is on top.
 	pub children: Vec<( Element<Msg>, HAlign, VAlign, f32, f32, f32 )>,
+	/// When `true`, [`preferred_size`](Self::preferred_size) reports the max of
+	/// children's intrinsic widths and heights instead of `(max_width, tallest)`.
 	pub fit_content: bool,
 }
 
@@ -65,6 +67,7 @@ impl<Msg: Clone> Stack<Msg>
 		Self { children: Vec::new(), fit_content: false }
 	}
 
+	/// Enable [`Self::fit_content`].
 	pub fn fit_content( mut self ) -> Self
 	{
 		self.fit_content = true;