refactor: Modularising the code base

[nikclayton]

This is a tracking issue for the work to split the code into multiple modules. This will:

• Improve build times (especially incremental build times) by allowing better parallelism. This is better for CI, and significantly better for developers, who don't need to spend as long waiting between builds
• Identify design flaws in the code (cycles in the dependency graph, inappropriate use of network types, etc) so they can be fixed
• Potentially allow some use of modules outside Pachli (e.g., a generic "Kotlin/Android Mastodon client library" could spin out from this)

The work is roughly:

• [x] Spin off a small set of core modules, https://github.com/pachli/pachli-android/pull/286
• [x] Break navigation dependency cycles, https://github.com/pachli/pachli-android/pull/305
• [x] #314
• [x] Move LoginActivity to a feature module #393
  • This is probably the smallest unit of code that can be moved, but will require moving BaseActivity as well.
  • Will probably require creating core:designsystem to hold key design resources
  • Will also demonstrate moving resources (e.g., strings) in to feature modules
• [x] Move About and related activities to a feature module, #405
• [x] Move Lists Activity and related UI to a feature module, #537
• [ ] Everything else

With "Everything else" to be fleshed out more after the initial split. My notes from previous discussions about similar work follow below.

---

Under this model we would have some core modules; at least types, database, network, designsystem, service (?), maybe one or two more.

And then the rest of the modules are organised around screens or complete features that the user uses.

So there'd be a hypothetical :screen:trending module that contains all the activity / fragment / viewmodel / resources / etc necessary to display the "Trending" screen, and that has dependencies on the relevant :core modules.

Thinking about these as screens or features mean that we don't fall in to the trap of trying to organise everything to mirror Android's class hierarchy.

There is a sweet spot where the module tree is of sufficient breadth and depth.

Too narrow and deep and we end up having to recompile too many things on every change. Too wide and shallow and too many unnecessary things get recompiled when a single module changes. Either way we lose the benefits of this sort of change.

A good rule of thumb is probably "What's the largest unit of UI that the user interacts with".

For example, there's currently AboutActivity and LicenseActivity. I could imagine a :screen:about module that contains both of those.

Or search -- that's multiple fragments (and an activity and viewmodel) -- but that would be in a :screen:search module, not three different modules like :screen:searchHashtag, :screen:searchAccounts, :screen:searchStatuses.