The legacy attrset option type for `firefox.profiles.<name>.bookmarks`
was accidentally removed in 9d55428. This adds back support for this
type by refactoring the bookmarks submodule. This also adds a new test
ensuring this won't happen again.
This splits the bookmarks submodule into a seperate file, to make it easier to maintain (like how the search module was previously split out in #5697).
This also refactors bookmarks to require a new force option, to be more explicit about overriding existing bookmarks.
The or operator is left associative, and since there is another
argument after the first term, the interpreter tries to apply whatever
the or-expression evaluates to. If the first operand is unset, it
evaluates to removeAttrs, and everything is fine, but if it is set to
a boolean (which is what it should be set to), then it tries to apply
a boolean to arguments, and we get a type error. Bracketing
explicitly with parentheses fixes this.
It presumably went unnoticed because not many people have tried
setting the option
`programs.firefox.profiles.<profile>.search.engines.<engine>.isAppProvided`.
Using a fixed application name in the salt for the search engine name
hash can break with minor branding changes. For example, LibreWolf 127
used the application name "LibreWolf", but in version 128 it is
"Firefox".
The proper name can be found in about:support -> Application Basics.
Because it doesn't have to be related to the product name visible in
most of the browser (for example in the window title and help menus),
we shouldn't rely on cfg.name for that.
The application name can be read from lib/*/application.ini and we can
use that if the browser was installed via Home Manager. If not, we can
fall back to cfg.name.
