Closes #264

• ChtAndroidApplication - By default an Android app uses the base android.app.Application class, but if you need to add any application-level hooks (as with the HiltAndroidApp annotation, you just need to extend Application with a custom class.
• SettingsDialogActivity - I decided to make this the example case for using Hilt dependency injection
  • Move class into components/settings_dialog package
  • Extract inner classes into their own files
  • No logic was changed in any of these classes besides updating the constructors/fields to work with Hilt
• SettingsStore:
  • Move various top-level classes in the file to instead be public inner-classes of SettingsStore
    • Cannot have multiple public top-level classes in the same file (honestly multiple top-level classes is an anti-pattern in Java anyway). But, to be able to access those classes from outside the base package, they need to be public.
    • To reduce the number of new files (and try to avoid the temptation for scope-creep) I have just moved these classes to be static inner classes of SettingsStore (these can be refactored more later).
    • Nothing was changed in these classes besides the visibility
  • Add SettingsStoreModule as a Hilt module to provide SettingsStore instances using Hilt. (Hilt does not understand, by default, how to call the SettingsStore.in method).