Composable settings exploration

[Mugurell]

Quick exploration into how the settings functionality could work:

• pure repository to offer the data about all settings items
  • uses a custom DSL for a natural way of building the tree of settings items for each screen
  • it handles also the logic for customizing certain items - different summary/enabled/toggled status before exposing the settings items details
• all logic handled in one Middleware
  • if a single Middleware becomes too complex we can introduce others for more specific usecases - telemetry, search
• "dumb" View that will only display the available data and emit Actions for user interactions
  • one Fragment allowing to integrate this within all other screens of the application
  • all nested settings screens implemented as composables
  • all setting item types implemented in compose and reused across different screens
• search functionality that uses the same data backing all settings screens as the data that can be queried by the user
  • in conjunction with the repository functionality it showcases how easy it is to include separate metadata based on which the search results can include more items than the ones of which the title or summary matches.
• Navigation 3 for managing the nested graph for all settings screens
  • I don't like that the NavGraph is strongly typed - needs different types for each "NavEntry", would've been great if we could use a generic "id" for knowing where to navigate
  • we could also handle the navigation in the new SettingsStore but Navigation 3 has nice conveniences like animations, back handling with automatic backstack update, etc.

[github-actions]

(Automated Close) Please do not file pull requests here, see https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html