Currently, many controls and skins invoke requestLayout() to trigger layout logic. However, requestLayout() marks the node and all its ancestors as NEEDS_LAYOUT, resulting in full layout passes across entire branches of the scene graph. This is often unnecessary and costly, particularly when layout bounds haven't changed.

Examples include:

- TextField and TextArea calling requestLayout() on every keypress or cursor move.
- Cursor shape updates or value bindings triggering full layout, even when visual bounds remain unchanged.

In many cases, the goal is simply to have layoutChildren() re-run locally, without triggering layout propagation up the scene graph.

Proposal:
Introduce a public method in Parent:

    /**
     * Requests that this node's layoutChildren method be called during the next layout pass,
     * without marking any parent nodes as needing layout. This is useful when internal layout
     * changes occur that do not affect the node's own layout bounds (such as content updates,
     * cursor position, or visual styling changes).
     * <p>
     * Unlike {@link #requestLayout()}, this method does not propagate layout invalidation up
     * the scene graph, avoiding unnecessary computation in parent nodes.
     * <p>
     * This request is batched asynchronously to occur once per "pulse", or frame of animation.
     */
    public void requestLayoutChildren();

This would:

- Mark the node as needing layout
- Avoid marking ancestors as NEEDS_LAYOUT (instead they're marked DIRTY_BRANCH)
- Only schedule layoutChildren() for the node during the next layout pass.

This mirrors the behavior of `setNeedsLayout(true)`, which is currently protected and not easily accessible.

Alternatively the method could be named `requestLocalLayout`.

Benefits:

- Provides a clear, efficient third option for control and skin developers between using requestLayout() (which is expensive due to full layout propagation) and manually updating visuals or child positions outside layoutChildren() (which is repetitive and error-prone).
- Encourages cleaner, more maintainable code by centralizing layout logic within layoutChildren() without paying the cost of full layout invalidation.
- Improves runtime performance, especially in large UIs or frequently-updating controls.