common options for scverse

To keep the discussion going: The first part (general settings base class) is now implemented, question is how we do the common options. I imagine something like a global settings class that subclasses the new Settings, let's call it GlobalSettings, and a SCVERSE_GLOBAL sentinel value. Using another base class inheriting from Settings, let's call it PackageSettings, we can check on attribute access if a value is set to SCVERSE_GLOBAL and return the global setting in that case, otherwise the actual value. Packages could then subclass PackageSettings.

This scheme allows users to change settings for specific packages, but I'm not sure where GlobalSettings is supposed to live so user can change global settings as well. Putting it into scverse-misc feels weird, since this is mostly a developer-oriented package. So far I can see three options:

1. have packages re-export the global settings instance
2. make a new package just for this
3. add a context manager to PackageSettings so users can do something like

with settings.set_global_settings:
    settings.n_jobs = 42

Originally posted by @ilia-kats in #8

No files or tests are named. Start by reviewing the existing Settings implementation and the linked discussion, then compare the proposed GlobalSettings, PackageSettings, sentinel, re-export, new-package, and context-manager options. Done means the project has an agreed design for common and package-specific settings, including where global settings live and how users change them.