Remove zbus dependency in dark-light

[bbb651]

We should wait for upstream to see what happens with the pull request: rust-dark-light/dark-light#40 (it also needs testing on macOS and windows).

Should I add a auto-detect-theme-zbus feature that activates zbus feature in dark-light? Afaik there's no other way for dark-light to know if zbus is used. The portal (which is the only usage of zbus) is only used as a fallback after DE specific methods, and this PR doesn't add support for the subscribe method that gives you a stream of theme yet (which does relay directly on portals and thus zbus), so it should very rarely be used anyway.

[hecrj]

What is the rationale? What is this addressing?

Also, depending on a fork I don't control is out of the question.

[bbb651]

zbus increases compile times and binary size significantly. If you're already using zbus (or ashpd which depends on it) it's unavoidable, but given that auto-detect-theme is enabled by default it makes iced needlessly heavy. (sorry, I thought I mentioned this, I might have accidentally deleted it)

I ran some cargo b --timings:

• With zbus: 43.09s
  cargo-timing-20241002T191034Z.html.gz
• Without zbus: 39.19s
  cargo-timing-20241002T185547Z.html.gz

I also ran cargo bloat --crates on tour on master:

 File  .text     Size Crate
 1.2%  11.5%   3.8MiB wgpu
 1.0%  10.3%   3.4MiB naga
 0.8%   7.7%   2.5MiB zbus
 0.8%   7.6%   2.5MiB image
 0.5%   5.2%   1.7MiB wgpu_hal
 0.5%   5.0%   1.6MiB winit
 0.5%   4.9%   1.6MiB std
 0.3%   3.1%   1.0MiB wgpu_core
 0.2%   2.3% 788.0KiB swash
 0.2%   2.2% 741.1KiB tiny_skia
 0.2%   2.1% 716.8KiB x11rb_protocol
 0.2%   2.0% 672.8KiB ttf_parser
 0.2%   1.9% 630.0KiB rustybuzz
 0.2%   1.6% 555.9KiB cosmic_text
 0.1%   1.4% 475.3KiB smithay_clipboard
 0.1%   1.2% 410.3KiB skrifa
 0.1%   1.0% 333.2KiB iced_wgpu
 0.1%   0.9% 304.0KiB jpeg_decoder
 0.1%   0.9% 289.5KiB wayland_client
 0.1%   0.9% 287.9KiB iced_tiny_skia
 2.4%  23.5%   7.7MiB And 190 more crates. Use -n N to show more.
10.1% 100.0%  33.0MiB .text section size, the file size is 327.6MiB

Note: numbers above are a result of guesswork. They are not 100% correct and never will be.

It's not as bad as I thought, but 10% longer initial compile time and 7% bigger binary size is still a pretty high price to pay for no value to the user. Feel free to copy my fork into the iced-rs org if you want to go ahead with this, I'd say we say for upstream and see before the next release (I'm not sure if it's breaking or not, it doesn't change the api, and while it technically changes the behavior but it should strictly work in more cases).