Model::clear() cloned the entire order VecDeque to iterate while
remove() mutated it, producing an O(n) allocation proportional to the
number of items — needless on a clear() which is going to drop all of
them anyway.
Replace the clone with std::mem::take(&mut self.order): we iterate the
taken VecDeque (transferring ownership), and the inner self.order.remove(index)
in each remove() call now finds position()==None and no-ops, since
self.order has been swapped with an empty default.
Same semantics, zero allocation. Noticeable on large nav/table models
(>100 items) and on apps that reset state frequently (settings pages,
file lists, context menus).
This also changes `widget::column::with_children` and
`widget::row::with_children` to take an `impl IntoIterator` instead
of a `Vec`, like the `iced` variants of these functions do.
This shouldn't be a breaking change since passing in a `Vec` will still
compile and function exactly as before.
(Using `iced::widget::Column::from_vec` or
`iced::widget::Row::from_vec` isn't possible, since the elements of the
`Vec` aren't checked, so the size of the resulting `Column` or `Row`
won't adapt to the size of its children. Perhaps a new function could
be added to mirror `iced`'s?)
