feat: update to 1.80.1 toolchain; dependency updates

[w-lfchen]

Description

specific details on some crate updates can be found below
motivated by and closes #1141
closes #1156
motivated by NixOS/nixpkgs#332957 (eww is currently building in nixpkgs through a lockfile patch)
supersedes #1137 (patch has been applied in a004136)
supersedes #809 (see below), therefore also closes #808
basic functionality tested (systray not tested, my config does not contain one)
reduces build times by dropping ~40 crates in the dependency tree

• update rust toolchain to 1.80.1
• update flake.lock
• update almost all dependencies, 4 have been left out, see below
• switch to nixfmt-rfc-style for nix formatting
• fix new lints
  note: there are warnings about unused struct fields now, this probably should be addressed

dbusmenu-glib breaks when automatically updating the missing dependencies

i don't know enough about this to even attempt to fix it, but i'd love to integrate a fix before opening this pr.

after 4cf9d2d

running cargo update --dry-run yields the following:

    Updating crates.io index
     Locking 6 packages to latest compatible versions
      Adding gdk-pixbuf-sys v0.20.0
      Adding gio-sys v0.20.0
      Adding glib v0.20.0
      Adding glib-macros v0.20.0
      Adding glib-sys v0.20.0
      Adding gobject-sys v0.20.0
note: pass `--verbose` to see 63 unchanged dependencies behind latest
warning: not updating lockfile due to dry run

When adding these crates by simply running cargo update, dbusmenu-glib fails to compile:

error[E0433]: failed to resolve: could not find `ObjectExt` in `glib`
   --> <home>/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dbusmenu-glib-0.1.0/src/auto/client.rs:203:15
    |
203 |         glib::ObjectExt::property(self.as_ref(), "dbus-name")
    |               ^^^^^^^^^ could not find `ObjectExt` in `glib`
    |
help: a struct with a similar name exists
    |
203 |         glib::Object::property(self.as_ref(), "dbus-name")
    |               ~~~~~~
help: consider importing this trait
    |
6   + use glib::prelude::ObjectExt;
    |
help: if you import `ObjectExt`, refer to it directly
    |
203 -         glib::ObjectExt::property(self.as_ref(), "dbus-name")
203 +         ObjectExt::property(self.as_ref(), "dbus-name")
    |

there are multiple errors like this one, since the dbusmenu-gtk3 crate and a few others that seem to be linked to it are auto-generated, something probably needs to be adjusted in the generation process.

before 4cf9d2d

running cargo update --dry-run yields the following:

     Locking 4 packages to latest compatible versions
      Adding gdk-pixbuf-sys v0.20.0
      Adding gio-sys v0.20.0
      Adding glib-sys v0.20.0
      Adding gobject-sys v0.20.0
note: pass `--verbose` to see 90 unchanged dependencies behind latest
warning: not updating lockfile due to dry run

note that everything seems to work without them and that gdk-pixbuf-sys seems to depend on the other 3.
When adding these crates, dbusmenu-glib fails to compile:

    |
586 |             FromGlibPtrContainer::from_glib_none(ffi::dbusmenu_menuitem_get_children(self.as_ref().to_glib_none().0))
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `glib::translate::FromGlibPtrArrayContainerAsVec<_, *mut glib_sys::GList>` is not implemented for `menuitem::Menuitem`, which is required by `Vec<menuitem::Menuitem>: glib::translate::FromGlibPtrContainer<_, *mut glib_sys::GList>`
    |
    = help: the following other types implement trait `glib::translate::FromGlibPtrArrayContainerAsVec<P, PP>`:
              <menuitem::Menuitem as glib::translate::FromGlibPtrArrayContainerAsVec<*mut DbusmenuMenuitem, *const *mut DbusmenuMenuitem>>
              <menuitem::Menuitem as glib::translate::FromGlibPtrArrayContainerAsVec<*mut DbusmenuMenuitem, *mut *mut DbusmenuMenuitem>>
    = note: required for `Vec<menuitem::Menuitem>` to implement `glib::translate::FromGlibPtrContainer<_, *mut glib_sys::GList>`

there are multiple errors like this one.

re-enable grass default features

80a5a45 re-enabled default features.
running cargo clean && cargo build produced the exact same compilation times for me, so the argument brought up in #606 no longer holds.

derive_more v1.0.0

the most notable breaking change is that now, all features should be enabled manually, which i've done.

Checklist

• I added my changes to CHANGELOG.md, if appropriate.
• I used cargo fmt to automatically format all code before committing
• I used nix fmt to automatically format all code before committing

[w-lfchen]

API change for more flexibility, doesn't cause issues

[w-lfchen]

everything should be up to date at the time of writing this

[elkowar]

Thank you so much for your work!