refactor(library): various Rust style optimizations

[ThomasFrans]

Lots of small fixes to the APIs and functions in the library module, mostly following best practices outlined in the Rust library guidelines. Changes outside the library module were mostly required changes after changing function signatures.

Describe your changes

• Function signature changes to make them more general (e.g. &[T] instead of Vec<T> when possible)
• Add documentation comments to most functions in the library module
• Remove a bunch of clones in favor of borrows when possible
• Change function signatures to accept mutable types directly instead of Arc<RWLock<T>> leaving locking up to the caller
• Restructure some function bodies to make their inner working clearer at first glance, but keeping their functionality the same
• Write serialized cache data directly to cache file instead of serializing to in-memory string first
• Add/remove variables to make code clearer

Checklist before requesting a review

• Documentation was updated (i.e. due to changes in keybindings, commands, etc.)
• Changelog was updated with relevant user-facing changes (eg. not dependency updates,
  not performance improvements, etc.)

[ThomasFrans]

I noticed a few things in the library module that were either old Rust things that can be written in a more elegant manner now or were hard to read. Also added documentation comments.

I payed attention to not cause deadlocks as there is a lot of locking (with read/write locks) going on in this code. I went over all the changes multiple times to double and triple check.

(I know I'm in for a lot of merge conflicts if the other documentation/refactor PRs are merged but ah, so be it 😩)

[hrkfdn]

Thanks so much, really liking this!

[ThomasFrans]

I'm glad, because I'm always worried that refactors might not be wanted as they could introduce bugs without having much functional benefit. I've been thinking about adding more tests for core stuff as well so some of the simpler issues that are popping up can be checked and prevented in the future. It would probably require some more refactoring work to make some of the code a bit more 'testable'.

PS: Don't want to push but I sent a message in the Matrix channel about wanting to do some refactoring work in the spotify module, as I currently find the control flow a bit hard to follow in places. I've been looking into some of the issues surrounding the token retrieval but I first wanted to ask whether I could try and restructure that code a bit as that might already help prevent issues in the future and make solving the current issues a bit easier. I'm just mentioning it here because I don't know whether you look at the Matrix room 🙂 Further details are in there.