Theme update

[wash2]

This is an implementation of the new design. It also removes some of the old code which had similar-ish functionality that we don't need anymore.

[wash2]

Oh I guess I need to wait for a new release of the palette crate with the oklch and oklab fix

[ids1024]

So the goal of using a thread_local! RefCell for the theme is so that it can be accessed for things like margins, without having to get a reference to the theme though Iced? (Which doesn't provide the theme where we'd normally need this.)

Are we sure we'd never try to access this from a different thread, even if Iced is using a multi-threaded async executor? If that happened, it would silently use a different instance of the variable local to that thread, which could be confusing.

This would also be a problem if multiple instance of Application are running in a single process, possibly with different themes... but hopefully that isn't an issue.

[mmstick]

There isn't a need to access the theme from a different thread because the view methods are always run from the same event loop on the main thread. Elements would otherwise require a static lifetime along with Send. The background threads are used only by commands and subscriptions.

I think we'd support concurrent execution of multiple application instances from the same thread, too. Similar to GTK, we could make a socket that listens for new application requests, and then register additional instances in our iced runtime, with events that are accompanied by an application instance ID.

[ids1024]

Yeah, I guess THEME is also set only from the main thread since it's handled in update, so it should be fine.

[ids1024]

If we find a better solution to using a thread local, perhaps with changes to how theming works in upstream Iced, we can change that. But it should be fine for now.

This otherwise looks good.